Re: Brooklyn Daemon Solution
Alex, In this case, I agree that wrapping java command in a service script may be the best choice. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 29 January 2016 at 20:50, Alex Heneveld wrote: > > Aleksandr, > > Is there anyone who needs this level of security? In my experience a > service calling a shell script is common, and in the cases where someone > needs something stronger they can build it. They possibly have custom > requirements there in any case. Bear in mind a daemon is going to > introduce a lot of complexity (many different OS's) so it would need to > offer major benefits to users or it's just not worth it, in my view. > > OTOH hopefully this is being considered as part of putting together RPM's > and DEB's and Docker images, as part of the Brooklyn build. In which case > the sooner we have that the better, because people do want those. Even > installing as a service I think is optional. > > FWIW Tomcat *suggest* the use of jsvc at [1] but they leave it for users > to implement. In practice I mainly see service scripts calling the > catalina start shell script which uses java -- not jsvc. > > Best > Alex > > [1] https://tomcat.apache.org/tomcat-7.0-doc/setup.html > > > > On 29/01/2016 15:58, Aleksandr Vasilev wrote: > >> Regarding the security implications when using a script vs a binary, >>> >> could you explain? >> It's not the difference between binary vs script, it's the different >> approach at launching the process. In my daemon I make sure child process >> is detached from the parent and can't get hold of any terminal sessions, >> so >> an attacker can't get any additional privileges. >> >> with file descriptor redirection, beyond stderr, stdout what are you >>> considering >>> >> here? >> Nothing more unless any other file descriptors are opened by Brooklyn. The >> daemon makes sure to close them all. >> >> are you intending this to be used outside of init? we'd have the config >>> >> set externally to the daemon >> Not at all, just suggesting it can be used in any type of service script >> >> we don't have to wrap a script surely? the init script doesn't have to >>> >> call the brooklyn script. >> Agreed, we can wrap java command, calling Brooklyn's Main class. Again I'm >> not sure this solution detaches the child process properly. >> >> >> Best Regards, >> Aleksandr Vasilev >> DevOps Engineer | Cloudsoft Corporation >> >> >> On 29 January 2016 at 18:45, John McCabe wrote: >> >> Hi Aleksandr, >>> >>> 1. Proper detaching from the parent process, making daemon more secure 2. Proper detaching from any TTYs, making daemon even more secure >>> Regarding the security implications when using a script vs a binary, >>> could >>> you explain? >>> >>> 3. Proper redirection of all file descriptors, helps with debugging and logging >>> with file descriptor redirection, beyond stderr, stdout what are you >>> considering here? >>> >>> 5. More flexible solution: ability to run Brooklyn with any arguments, service script will have "brooklyn launch" part hardcoded and will >>> require >>> to edit the code each time you need to run it with the new args. >>> are you intending this to be used outside of init? we'd have the config >>> set >>> externally to the daemon >>> >>> Overall I see the native daemon solution as more traditional and >>> compliant >>> to Linux standards than just wrapping bash script in yet another script. >>> we don't have to wrap a script surely? the init script doesn't have to >>> call >>> the brooklyn script. >>> >>> All the best, >>> John >>> >>> On Fri, Jan 29, 2016 at 2:58 PM, Aleksandr Vasilev < >>> aleksandr.vasi...@cloudsoftcorp.com> wrote: >>> >>> Hi Alex, The advantages of having a native daemon in my opinion are: 1. Proper detaching from the parent process, making daemon more secure 2. Proper detaching from any TTYs, making daemon even more secure 3. Proper redirection of all file descriptors, helps with debugging and logging 4. More portable solution, as the daemon can be used in any type of >>> service >>> scripts or even on its own, not only systemd script 5. More flexible solution: ability to run Brooklyn with any arguments, service script will have "brooklyn launch" part hardcoded and will >>> require >>> to edit the code each time you need to run it with the new args. Overall I see the native daemon solution as more traditional and >>> compliant >>> to Linux standards than just wrapping bash script in yet another script. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 29 January 2016 at 17:30, John McCabe wrote: [bumping so aleks can see the thread] > > On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy < > andrew.kenn...@cloudsoftcorp.com> wrote: > > Or what about running a Brooklyn Docker image as a syste
Re: Brooklyn Daemon Solution
Aleksandr, Is there anyone who needs this level of security? In my experience a service calling a shell script is common, and in the cases where someone needs something stronger they can build it. They possibly have custom requirements there in any case. Bear in mind a daemon is going to introduce a lot of complexity (many different OS's) so it would need to offer major benefits to users or it's just not worth it, in my view. OTOH hopefully this is being considered as part of putting together RPM's and DEB's and Docker images, as part of the Brooklyn build. In which case the sooner we have that the better, because people do want those. Even installing as a service I think is optional. FWIW Tomcat *suggest* the use of jsvc at [1] but they leave it for users to implement. In practice I mainly see service scripts calling the catalina start shell script which uses java -- not jsvc. Best Alex [1] https://tomcat.apache.org/tomcat-7.0-doc/setup.html On 29/01/2016 15:58, Aleksandr Vasilev wrote: Regarding the security implications when using a script vs a binary, could you explain? It's not the difference between binary vs script, it's the different approach at launching the process. In my daemon I make sure child process is detached from the parent and can't get hold of any terminal sessions, so an attacker can't get any additional privileges. with file descriptor redirection, beyond stderr, stdout what are you considering here? Nothing more unless any other file descriptors are opened by Brooklyn. The daemon makes sure to close them all. are you intending this to be used outside of init? we'd have the config set externally to the daemon Not at all, just suggesting it can be used in any type of service script we don't have to wrap a script surely? the init script doesn't have to call the brooklyn script. Agreed, we can wrap java command, calling Brooklyn's Main class. Again I'm not sure this solution detaches the child process properly. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 29 January 2016 at 18:45, John McCabe wrote: Hi Aleksandr, 1. Proper detaching from the parent process, making daemon more secure 2. Proper detaching from any TTYs, making daemon even more secure Regarding the security implications when using a script vs a binary, could you explain? 3. Proper redirection of all file descriptors, helps with debugging and logging with file descriptor redirection, beyond stderr, stdout what are you considering here? 5. More flexible solution: ability to run Brooklyn with any arguments, service script will have "brooklyn launch" part hardcoded and will require to edit the code each time you need to run it with the new args. are you intending this to be used outside of init? we'd have the config set externally to the daemon Overall I see the native daemon solution as more traditional and compliant to Linux standards than just wrapping bash script in yet another script. we don't have to wrap a script surely? the init script doesn't have to call the brooklyn script. All the best, John On Fri, Jan 29, 2016 at 2:58 PM, Aleksandr Vasilev < aleksandr.vasi...@cloudsoftcorp.com> wrote: Hi Alex, The advantages of having a native daemon in my opinion are: 1. Proper detaching from the parent process, making daemon more secure 2. Proper detaching from any TTYs, making daemon even more secure 3. Proper redirection of all file descriptors, helps with debugging and logging 4. More portable solution, as the daemon can be used in any type of service scripts or even on its own, not only systemd script 5. More flexible solution: ability to run Brooklyn with any arguments, service script will have "brooklyn launch" part hardcoded and will require to edit the code each time you need to run it with the new args. Overall I see the native daemon solution as more traditional and compliant to Linux standards than just wrapping bash script in yet another script. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 29 January 2016 at 17:30, John McCabe wrote: [bumping so aleks can see the thread] On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy < andrew.kenn...@cloudsoftcorp.com> wrote: Or what about running a Brooklyn Docker image as a systemd service! - http://container-solutions.com/running-docker-containers-with-systemd/ - https://github.com/ibuildthecloud/systemd-docker Andrew. On Thu, 28 Jan 2016 at 16:34 Alex Heneveld < alex.henev...@cloudsoftcorp.com> wrote: Hi Aleksandr- What's the advantage of a native daemon over just wrapping it as a linux service script ? Best Alex On 28/01/2016 11:32, Aleksandr Vasilev wrote: Hello everyone! I spent last few days looking at the solution to run Brooklyn process as a daemon and found two options: 1. Run daemon via Apache Commons Daemon (jsvc) 2. Write a custom daemon in C Both solutions has its own pros and cons, so let's look at what I think
Re: Brooklyn Daemon Solution
> Regarding the security implications when using a script vs a binary, could you explain? It's not the difference between binary vs script, it's the different approach at launching the process. In my daemon I make sure child process is detached from the parent and can't get hold of any terminal sessions, so an attacker can't get any additional privileges. >with file descriptor redirection, beyond stderr, stdout what are you >considering here? Nothing more unless any other file descriptors are opened by Brooklyn. The daemon makes sure to close them all. >are you intending this to be used outside of init? we'd have the config set externally to the daemon Not at all, just suggesting it can be used in any type of service script >we don't have to wrap a script surely? the init script doesn't have to call the brooklyn script. Agreed, we can wrap java command, calling Brooklyn's Main class. Again I'm not sure this solution detaches the child process properly. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 29 January 2016 at 18:45, John McCabe wrote: > Hi Aleksandr, > > > 1. Proper detaching from the parent process, making daemon more secure > > 2. Proper detaching from any TTYs, making daemon even more secure > > Regarding the security implications when using a script vs a binary, could > you explain? > > > 3. Proper redirection of all file descriptors, helps with debugging and > > logging > > with file descriptor redirection, beyond stderr, stdout what are you > considering here? > > > 5. More flexible solution: ability to run Brooklyn with any arguments, > > service script will have "brooklyn launch" part hardcoded and will > require > > to edit the code each time you need to run it with the new args. > > are you intending this to be used outside of init? we'd have the config set > externally to the daemon > > > Overall I see the native daemon solution as more traditional and > compliant > > to Linux standards than just wrapping bash script in yet another script. > > we don't have to wrap a script surely? the init script doesn't have to call > the brooklyn script. > > All the best, > John > > On Fri, Jan 29, 2016 at 2:58 PM, Aleksandr Vasilev < > aleksandr.vasi...@cloudsoftcorp.com> wrote: > > > Hi Alex, > > > > The advantages of having a native daemon in my opinion are: > > 1. Proper detaching from the parent process, making daemon more secure > > 2. Proper detaching from any TTYs, making daemon even more secure > > 3. Proper redirection of all file descriptors, helps with debugging and > > logging > > 4. More portable solution, as the daemon can be used in any type of > service > > scripts or even on its own, not only systemd script > > 5. More flexible solution: ability to run Brooklyn with any arguments, > > service script will have "brooklyn launch" part hardcoded and will > require > > to edit the code each time you need to run it with the new args. > > > > Overall I see the native daemon solution as more traditional and > compliant > > to Linux standards than just wrapping bash script in yet another script. > > > > Best Regards, > > Aleksandr Vasilev > > DevOps Engineer | Cloudsoft Corporation > > > > On 29 January 2016 at 17:30, John McCabe wrote: > > > > > [bumping so aleks can see the thread] > > > > > > On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy < > > > andrew.kenn...@cloudsoftcorp.com> wrote: > > > > > > > Or what about running a Brooklyn Docker image as a systemd service! > > > > > > > > - > > http://container-solutions.com/running-docker-containers-with-systemd/ > > > > - https://github.com/ibuildthecloud/systemd-docker > > > > > > > > Andrew. > > > > > > > > On Thu, 28 Jan 2016 at 16:34 Alex Heneveld < > > > > alex.henev...@cloudsoftcorp.com> > > > > wrote: > > > > > > > > > > > > > > Hi Aleksandr- > > > > > > > > > > What's the advantage of a native daemon over just wrapping it as a > > > linux > > > > > service script ? > > > > > > > > > > Best > > > > > Alex > > > > > > > > > > > > > > > On 28/01/2016 11:32, Aleksandr Vasilev wrote: > > > > > > Hello everyone! > > > > > > > > > > > > I spent last few days looking at the solution to run Brooklyn > > process > > > > as > > > > > a > > > > > > daemon and found two options: > > > > > > 1. Run daemon via Apache Commons Daemon (jsvc) > > > > > > 2. Write a custom daemon in C > > > > > > > > > > > > Both solutions has its own pros and cons, so let's look at what I > > > think > > > > > > they are: > > > > > > > > > > > > JSVC: > > > > > > Pros: > > > > > > - Ready to use solution. Running a daemon via jsvc is very > similar > > to > > > > > > running java application from the command line with similar > > arguments > > > > > > passed. > > > > > > - Builds as usual in Maven > > > > > > > > > > > > Cons: > > > > > > - Still requires you to write daemon code, which in my opinion > > kills > > > > the > > > > > > out-of-the-box usability > > > > > > - Has tons of bugs, including: not been able to find classes in >
Re: Brooklyn Daemon Solution
Hi Aleksandr, > 1. Proper detaching from the parent process, making daemon more secure > 2. Proper detaching from any TTYs, making daemon even more secure Regarding the security implications when using a script vs a binary, could you explain? > 3. Proper redirection of all file descriptors, helps with debugging and > logging with file descriptor redirection, beyond stderr, stdout what are you considering here? > 5. More flexible solution: ability to run Brooklyn with any arguments, > service script will have "brooklyn launch" part hardcoded and will require > to edit the code each time you need to run it with the new args. are you intending this to be used outside of init? we'd have the config set externally to the daemon > Overall I see the native daemon solution as more traditional and compliant > to Linux standards than just wrapping bash script in yet another script. we don't have to wrap a script surely? the init script doesn't have to call the brooklyn script. All the best, John On Fri, Jan 29, 2016 at 2:58 PM, Aleksandr Vasilev < aleksandr.vasi...@cloudsoftcorp.com> wrote: > Hi Alex, > > The advantages of having a native daemon in my opinion are: > 1. Proper detaching from the parent process, making daemon more secure > 2. Proper detaching from any TTYs, making daemon even more secure > 3. Proper redirection of all file descriptors, helps with debugging and > logging > 4. More portable solution, as the daemon can be used in any type of service > scripts or even on its own, not only systemd script > 5. More flexible solution: ability to run Brooklyn with any arguments, > service script will have "brooklyn launch" part hardcoded and will require > to edit the code each time you need to run it with the new args. > > Overall I see the native daemon solution as more traditional and compliant > to Linux standards than just wrapping bash script in yet another script. > > Best Regards, > Aleksandr Vasilev > DevOps Engineer | Cloudsoft Corporation > > On 29 January 2016 at 17:30, John McCabe wrote: > > > [bumping so aleks can see the thread] > > > > On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy < > > andrew.kenn...@cloudsoftcorp.com> wrote: > > > > > Or what about running a Brooklyn Docker image as a systemd service! > > > > > > - > http://container-solutions.com/running-docker-containers-with-systemd/ > > > - https://github.com/ibuildthecloud/systemd-docker > > > > > > Andrew. > > > > > > On Thu, 28 Jan 2016 at 16:34 Alex Heneveld < > > > alex.henev...@cloudsoftcorp.com> > > > wrote: > > > > > > > > > > > Hi Aleksandr- > > > > > > > > What's the advantage of a native daemon over just wrapping it as a > > linux > > > > service script ? > > > > > > > > Best > > > > Alex > > > > > > > > > > > > On 28/01/2016 11:32, Aleksandr Vasilev wrote: > > > > > Hello everyone! > > > > > > > > > > I spent last few days looking at the solution to run Brooklyn > process > > > as > > > > a > > > > > daemon and found two options: > > > > > 1. Run daemon via Apache Commons Daemon (jsvc) > > > > > 2. Write a custom daemon in C > > > > > > > > > > Both solutions has its own pros and cons, so let's look at what I > > think > > > > > they are: > > > > > > > > > > JSVC: > > > > > Pros: > > > > > - Ready to use solution. Running a daemon via jsvc is very similar > to > > > > > running java application from the command line with similar > arguments > > > > > passed. > > > > > - Builds as usual in Maven > > > > > > > > > > Cons: > > > > > - Still requires you to write daemon code, which in my opinion > kills > > > the > > > > > out-of-the-box usability > > > > > - Has tons of bugs, including: not been able to find classes in > > > > classpath, > > > > > not been able to run by non-root users, not been able to run on > > several > > > > > *nix systems (Mac OS, BSD) > > > > > - The codebase hasn't changed since 2013 and seems abandoned > > > > > - SVN repo often isn't accessible for some reason, right now the > > > > webserver > > > > > returns 503 error code: > > > > > http://svn.apache.org/viewvc/commons/proper/daemon/trunk/ > > > > > > > > > > Custom Daemon (written in C): > > > > > Pros: > > > > > - Cross-platform, runs on any *nix system supported by Brooklyn > > > > > - Very little code to maintain > > > > > - Independent from third-party solutions, requires only gcc to > build > > > > > - Easy to make LSB-compliant init scripts to control the daemon > > > > > > > > > > Cons: > > > > > - Requires some overhead to build C code in Maven > > > > > > > > > > Having all these options considered, I propose writing daemon for > > > Apache > > > > > Brooklyn in C language and use gcc compiler to build it. It will > > > require > > > > > introducing some changes to Maven build process, but there are > plenty > > > of > > > > > solutions for doing this, such as Maven NAR plugin, which is > actively > > > > > maintained: > > > > > https://github.com/maven-nar/nar-maven-plugin > > > > > > > > > > Best Regards, > > > > > Aleksandr Va
Re: Brooklyn Daemon Solution
Hi Alex, The advantages of having a native daemon in my opinion are: 1. Proper detaching from the parent process, making daemon more secure 2. Proper detaching from any TTYs, making daemon even more secure 3. Proper redirection of all file descriptors, helps with debugging and logging 4. More portable solution, as the daemon can be used in any type of service scripts or even on its own, not only systemd script 5. More flexible solution: ability to run Brooklyn with any arguments, service script will have "brooklyn launch" part hardcoded and will require to edit the code each time you need to run it with the new args. Overall I see the native daemon solution as more traditional and compliant to Linux standards than just wrapping bash script in yet another script. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 29 January 2016 at 17:30, John McCabe wrote: > [bumping so aleks can see the thread] > > On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy < > andrew.kenn...@cloudsoftcorp.com> wrote: > > > Or what about running a Brooklyn Docker image as a systemd service! > > > > - http://container-solutions.com/running-docker-containers-with-systemd/ > > - https://github.com/ibuildthecloud/systemd-docker > > > > Andrew. > > > > On Thu, 28 Jan 2016 at 16:34 Alex Heneveld < > > alex.henev...@cloudsoftcorp.com> > > wrote: > > > > > > > > Hi Aleksandr- > > > > > > What's the advantage of a native daemon over just wrapping it as a > linux > > > service script ? > > > > > > Best > > > Alex > > > > > > > > > On 28/01/2016 11:32, Aleksandr Vasilev wrote: > > > > Hello everyone! > > > > > > > > I spent last few days looking at the solution to run Brooklyn process > > as > > > a > > > > daemon and found two options: > > > > 1. Run daemon via Apache Commons Daemon (jsvc) > > > > 2. Write a custom daemon in C > > > > > > > > Both solutions has its own pros and cons, so let's look at what I > think > > > > they are: > > > > > > > > JSVC: > > > > Pros: > > > > - Ready to use solution. Running a daemon via jsvc is very similar to > > > > running java application from the command line with similar arguments > > > > passed. > > > > - Builds as usual in Maven > > > > > > > > Cons: > > > > - Still requires you to write daemon code, which in my opinion kills > > the > > > > out-of-the-box usability > > > > - Has tons of bugs, including: not been able to find classes in > > > classpath, > > > > not been able to run by non-root users, not been able to run on > several > > > > *nix systems (Mac OS, BSD) > > > > - The codebase hasn't changed since 2013 and seems abandoned > > > > - SVN repo often isn't accessible for some reason, right now the > > > webserver > > > > returns 503 error code: > > > > http://svn.apache.org/viewvc/commons/proper/daemon/trunk/ > > > > > > > > Custom Daemon (written in C): > > > > Pros: > > > > - Cross-platform, runs on any *nix system supported by Brooklyn > > > > - Very little code to maintain > > > > - Independent from third-party solutions, requires only gcc to build > > > > - Easy to make LSB-compliant init scripts to control the daemon > > > > > > > > Cons: > > > > - Requires some overhead to build C code in Maven > > > > > > > > Having all these options considered, I propose writing daemon for > > Apache > > > > Brooklyn in C language and use gcc compiler to build it. It will > > require > > > > introducing some changes to Maven build process, but there are plenty > > of > > > > solutions for doing this, such as Maven NAR plugin, which is actively > > > > maintained: > > > > https://github.com/maven-nar/nar-maven-plugin > > > > > > > > Best Regards, > > > > Aleksandr Vasilev > > > > DevOps Engineer | Cloudsoft Corporation > > > > > > > > > > -- > > > > Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft > > >
Re: Brooklyn Daemon Solution
[bumping so aleks can see the thread] On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy < andrew.kenn...@cloudsoftcorp.com> wrote: > Or what about running a Brooklyn Docker image as a systemd service! > > - http://container-solutions.com/running-docker-containers-with-systemd/ > - https://github.com/ibuildthecloud/systemd-docker > > Andrew. > > On Thu, 28 Jan 2016 at 16:34 Alex Heneveld < > alex.henev...@cloudsoftcorp.com> > wrote: > > > > > Hi Aleksandr- > > > > What's the advantage of a native daemon over just wrapping it as a linux > > service script ? > > > > Best > > Alex > > > > > > On 28/01/2016 11:32, Aleksandr Vasilev wrote: > > > Hello everyone! > > > > > > I spent last few days looking at the solution to run Brooklyn process > as > > a > > > daemon and found two options: > > > 1. Run daemon via Apache Commons Daemon (jsvc) > > > 2. Write a custom daemon in C > > > > > > Both solutions has its own pros and cons, so let's look at what I think > > > they are: > > > > > > JSVC: > > > Pros: > > > - Ready to use solution. Running a daemon via jsvc is very similar to > > > running java application from the command line with similar arguments > > > passed. > > > - Builds as usual in Maven > > > > > > Cons: > > > - Still requires you to write daemon code, which in my opinion kills > the > > > out-of-the-box usability > > > - Has tons of bugs, including: not been able to find classes in > > classpath, > > > not been able to run by non-root users, not been able to run on several > > > *nix systems (Mac OS, BSD) > > > - The codebase hasn't changed since 2013 and seems abandoned > > > - SVN repo often isn't accessible for some reason, right now the > > webserver > > > returns 503 error code: > > > http://svn.apache.org/viewvc/commons/proper/daemon/trunk/ > > > > > > Custom Daemon (written in C): > > > Pros: > > > - Cross-platform, runs on any *nix system supported by Brooklyn > > > - Very little code to maintain > > > - Independent from third-party solutions, requires only gcc to build > > > - Easy to make LSB-compliant init scripts to control the daemon > > > > > > Cons: > > > - Requires some overhead to build C code in Maven > > > > > > Having all these options considered, I propose writing daemon for > Apache > > > Brooklyn in C language and use gcc compiler to build it. It will > require > > > introducing some changes to Maven build process, but there are plenty > of > > > solutions for doing this, such as Maven NAR plugin, which is actively > > > maintained: > > > https://github.com/maven-nar/nar-maven-plugin > > > > > > Best Regards, > > > Aleksandr Vasilev > > > DevOps Engineer | Cloudsoft Corporation > > > > > > > -- > > Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft >
Re: Brooklyn Daemon Solution
Or what about running a Brooklyn Docker image as a systemd service! - http://container-solutions.com/running-docker-containers-with-systemd/ - https://github.com/ibuildthecloud/systemd-docker Andrew. On Thu, 28 Jan 2016 at 16:34 Alex Heneveld wrote: > > Hi Aleksandr- > > What's the advantage of a native daemon over just wrapping it as a linux > service script ? > > Best > Alex > > > On 28/01/2016 11:32, Aleksandr Vasilev wrote: > > Hello everyone! > > > > I spent last few days looking at the solution to run Brooklyn process as > a > > daemon and found two options: > > 1. Run daemon via Apache Commons Daemon (jsvc) > > 2. Write a custom daemon in C > > > > Both solutions has its own pros and cons, so let's look at what I think > > they are: > > > > JSVC: > > Pros: > > - Ready to use solution. Running a daemon via jsvc is very similar to > > running java application from the command line with similar arguments > > passed. > > - Builds as usual in Maven > > > > Cons: > > - Still requires you to write daemon code, which in my opinion kills the > > out-of-the-box usability > > - Has tons of bugs, including: not been able to find classes in > classpath, > > not been able to run by non-root users, not been able to run on several > > *nix systems (Mac OS, BSD) > > - The codebase hasn't changed since 2013 and seems abandoned > > - SVN repo often isn't accessible for some reason, right now the > webserver > > returns 503 error code: > > http://svn.apache.org/viewvc/commons/proper/daemon/trunk/ > > > > Custom Daemon (written in C): > > Pros: > > - Cross-platform, runs on any *nix system supported by Brooklyn > > - Very little code to maintain > > - Independent from third-party solutions, requires only gcc to build > > - Easy to make LSB-compliant init scripts to control the daemon > > > > Cons: > > - Requires some overhead to build C code in Maven > > > > Having all these options considered, I propose writing daemon for Apache > > Brooklyn in C language and use gcc compiler to build it. It will require > > introducing some changes to Maven build process, but there are plenty of > > solutions for doing this, such as Maven NAR plugin, which is actively > > maintained: > > https://github.com/maven-nar/nar-maven-plugin > > > > Best Regards, > > Aleksandr Vasilev > > DevOps Engineer | Cloudsoft Corporation > > > > -- Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
Re: Brooklyn Daemon Solution
Hi Aleksandr- What's the advantage of a native daemon over just wrapping it as a linux service script ? Best Alex On 28/01/2016 11:32, Aleksandr Vasilev wrote: Hello everyone! I spent last few days looking at the solution to run Brooklyn process as a daemon and found two options: 1. Run daemon via Apache Commons Daemon (jsvc) 2. Write a custom daemon in C Both solutions has its own pros and cons, so let's look at what I think they are: JSVC: Pros: - Ready to use solution. Running a daemon via jsvc is very similar to running java application from the command line with similar arguments passed. - Builds as usual in Maven Cons: - Still requires you to write daemon code, which in my opinion kills the out-of-the-box usability - Has tons of bugs, including: not been able to find classes in classpath, not been able to run by non-root users, not been able to run on several *nix systems (Mac OS, BSD) - The codebase hasn't changed since 2013 and seems abandoned - SVN repo often isn't accessible for some reason, right now the webserver returns 503 error code: http://svn.apache.org/viewvc/commons/proper/daemon/trunk/ Custom Daemon (written in C): Pros: - Cross-platform, runs on any *nix system supported by Brooklyn - Very little code to maintain - Independent from third-party solutions, requires only gcc to build - Easy to make LSB-compliant init scripts to control the daemon Cons: - Requires some overhead to build C code in Maven Having all these options considered, I propose writing daemon for Apache Brooklyn in C language and use gcc compiler to build it. It will require introducing some changes to Maven build process, but there are plenty of solutions for doing this, such as Maven NAR plugin, which is actively maintained: https://github.com/maven-nar/nar-maven-plugin Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation
Brooklyn Daemon Solution
Hello everyone! I spent last few days looking at the solution to run Brooklyn process as a daemon and found two options: 1. Run daemon via Apache Commons Daemon (jsvc) 2. Write a custom daemon in C Both solutions has its own pros and cons, so let's look at what I think they are: JSVC: Pros: - Ready to use solution. Running a daemon via jsvc is very similar to running java application from the command line with similar arguments passed. - Builds as usual in Maven Cons: - Still requires you to write daemon code, which in my opinion kills the out-of-the-box usability - Has tons of bugs, including: not been able to find classes in classpath, not been able to run by non-root users, not been able to run on several *nix systems (Mac OS, BSD) - The codebase hasn't changed since 2013 and seems abandoned - SVN repo often isn't accessible for some reason, right now the webserver returns 503 error code: http://svn.apache.org/viewvc/commons/proper/daemon/trunk/ Custom Daemon (written in C): Pros: - Cross-platform, runs on any *nix system supported by Brooklyn - Very little code to maintain - Independent from third-party solutions, requires only gcc to build - Easy to make LSB-compliant init scripts to control the daemon Cons: - Requires some overhead to build C code in Maven Having all these options considered, I propose writing daemon for Apache Brooklyn in C language and use gcc compiler to build it. It will require introducing some changes to Maven build process, but there are plenty of solutions for doing this, such as Maven NAR plugin, which is actively maintained: https://github.com/maven-nar/nar-maven-plugin Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation
