quoted from systemd.serivce manual page
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
I believe zookeeper is designed to fail (join and leave without being strict at the exact time when it's read)
I guess zookeeper do create a pid file in (/var/lib/zookeeper/data or /var/lib/zookeeper/log ) I'm not sure.
is there a specific reason related to how zookeeper work for doing so?
is logj configured properly to use jouranld?
because I see in .service
SyslogIdentifier=zookeeper
On Mon, Jan 11, 2016 at 5:41 PM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
On Mon, 11.01.16 15:32, Muayyad AlSadi (alsadi@xxxxxxxxx) wrote:
> > "Type=forking" implies that depending services are started *after* the
> forking and the service is *really* read (it needs depending on the
> signatures a longer time for initalization)
>
> but I guess it needs a PID file path to work properly which is not the case.
>
> I'm not really sure about the readyness thingy in case of zookeeper but I
> guess both simple and forking do not know when exactly the when port is
> opened (I guess only notify does that)
Type=simple is useful primarily for daemons which either use socket
activation (recommended) to establish their communication channels, or
which have no comunication channels. For daemons which establish
communication channels on their own, one should use Type=notify or
Type=forking instead, since these permit notifying systemd about when
the daemon has finished initialization, so that systemd can start any
dependending daemons only after that initialization is complete and
thus the daemon may be talked to.
Note that socket activation, as well as Type=notify require explicit
support in the daemon, while Type=forking is compatible with classic
UNIX double-forking daemons.
With Type=forking it's recommended to specify a PIDFile= which systemd
can read the daemon's main process from. If none is specified, systemd
will try to guess the main daemon process, but that only works
reliably if the daemon is a single-process daemon really.
Lennart
--
Lennart Poettering, Red Hat
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
