brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksandr Vasilev <aleksandr.vasi...@cloudsoftcorp.com>
Subject Re: Brooklyn Daemon Solution
Date Fri, 29 Jan 2016 14:58:03 GMT
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 <john@johnmccabe.net> wrote:

> [bumping so aleks can see the thread]
>
> On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy <
> andrew.kennedy@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.heneveld@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message