Re: is there a reason for starting zookeeper.service in background?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 11, 2016 at 11:41 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
On Mon, 11.01.16 18:30, Muayyad AlSadi (alsadi@xxxxxxxxx) wrote:

> quoted from systemd.serivce manual page
>
> >> it is recommended to also use the PIDFile= option, so that systemd can
> identify the main process of the daemon.
>
> my point is that having a child double forked does not mean Zookeeper TCP
> port is ready which is as bad as simple which is also does not indicate
> when it's ready

Well, then Zookeeper is simply broken.

Classic UNIX daemons double fork, and only exit in the parent after
the main daemon process (i.e. the "parent"'s grandchild) informed it
that start-up is now complete, and that most importantly pretty much
means two things:

     A) The communication channels are established
     B) The PID file is now written

That the parent process hangs around until the main daemon did these
two jobs is essential on SysV, so that shell processing can work, as
the parent returning is the trigger for invoking the next shell
script line, which then is supposed to rely on the daemon being up.

systemd makes the same assumptions on SysV here, even though no shell
scriping is involved. If Zookeper doesn't get this right it's borked
on SysV the same way as on systemd, and really should get fixed.

See daemon(7) on some docs how a classic UNIX daemon is supposed to
start up.

Lennart

Hi,

I'm a co-maintainer for ZooKeeper, and I'd like to help get this right, if possible. More importantly, I'm interested in setting a precedent for Java system services in systemd. So, forgive my ignorance, but what exactly is the generally recommended way of launching Java-based applications as system services in systemd? Is there a good model to follow? A Java service that gets this right?

Also, as I understand it, Java processes don't really fork in any way that's useful here. The JVM has it's own internal threading model. So, what's the best way for them to play nice with systemd? Should they all be simple? Or should they all be launched by a shell script which implements the double-forking paradigm? If the latter, wouldn't that add a lot of complication that systemd is designed to eliminate with the simplicity of writing units?
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux