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

[Muayyad AlSadi]

>> 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.

sorry it's just me. I forget that the classic UNIX double fork do listen
before the double fork not after it.
I'm sorry again it would be for sure ready when the inner child is forked
if it was done the classical UNIX way (but it seems not, it's done by bash
see below)

but anyway. let's discuss how it should be done properly.


> recommended way of launching Java-based applications as system services
in systemd?

usually I love to pass -f to solr and I was considering passing "
start-foreground"  to make it foreground
because I don't have enough knowledge/trust in their bash scripts (and life
is to short to read them and review them)
so I just short-circuit all background and process management and make
systemd care about that.
this is "my way" not "the recommended way".
and of course I would love hear from people like you "the right way".

for example do they have a monitoring sub-process (to do auto restart)? how
do they handle reload or restart ..etc?
if someone run the bash script directly telling it to restart what would
happen ...etc.
all this is eliminated. I don't really care when solr is actually ready
because my web application does not need solr to start (refresh page would
work)

> Or should they all be launched by a shell script which implements the
double-forking paradigm?
> is that just guessing or proven?

I used to believe that the double forking is done by java (after the socket
is listening to requests) not bash.
but the bash script contains lines like this

nohup "$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1
< /dev/null &
if [ $? -eq 0 ]
...
/bin/echo -n $! > "$ZOOPIDFILE"

so I believe the forking is done by bash without a ready socket.

@Reindl.Harald the above bash is doing the fork, without any listening
socket. so it's not guessing.

if you are like me don't really care about the exact time the socket is
ready just foreground with type=simple
if you do care about that either in the part that need it use nc magic

for i in `seq 9`; do echo "" | nc localhost $PORT 1>/dev/null 2>/dev/null
&& echo "$PORT is up" && break; sleep 0.$i; done
you can wrap it in /bin/bash -c "" if you need an absolute path.


> What about a simple JNI wrapper to sd_notify(3)? Shouldn't be hard, gives
the process a chance to actually signal when its' ready.

you can use "systemd-notify" in the bash script above just before "&& break"

but I would still go with foreground.

@Lennart Poettering is there a way to use something like "ExecStartPost="
do the the notify with type=simple?






On Mon, Jan 11, 2016 at 10:59 PM, Alec Leamas  wrote:

> On 11/01/16 21:19, Christopher wrote:
>
> 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?
>>
>>
> What about a simple JNI wrapper to sd_notify(3)? Shouldn't be hard, gives
> the process a chance to actually signal when its' ready.
>
> Cheers!
>
> --alec
>
> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>>
>> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Reindl Harald]

Am 12.01.2016 um 09:22 schrieb Muayyad AlSadi:

 nohup "$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
 -cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT"
2>&1 < /dev/null &
 if [ $? -eq 0 ]
...
 /bin/echo -n $! > "$ZOOPIDFILE"

so I believe the forking is done by bash without a ready socket.

@Reindl.Harald the above bash is doing the fork, without any listening
socket. so it's not guessing


the problem here is the bash script wrapped around



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

> the problem here is the bash script wrapped around

just pass "start-foreground" and it will be short-circuit
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

> the problem here is the bash script wrapped around

in the good old days of solr there used a param passed to solr.jar to make
the fork magic in java (maybe it was --daemon)
but now it's done in bash with "nohup" followed by "while true  lsof
-PniTCP:$SOLR_PORT -sTCP:LISTEN" to detect if it's up before exit

the zookeeper bash script does not have such lsof check and I tried to make
it print usage

Usage: ZooKeeperServerMain configfile | port datadir [ticktime] [maxcnxns]

no daemon-related option

so the best choice IMHO is to short-circuit all the bash forking




On Tue, Jan 12, 2016 at 11:34 AM, Muayyad AlSadi  wrote:

> > the problem here is the bash script wrapped around
>
> just pass "start-foreground" and it will be short-circuit
>
>
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Alec Leamas]

On 12/01/16 10:54, Muayyad AlSadi wrote:

the problem here is the bash script wrapped around


in the good old days of solr there used a param passed to solr.jar to
make the fork magic in java (maybe it was --daemon)
but now it's done in bash with "nohup" followed by "while true  lsof
-PniTCP:$SOLR_PORT -sTCP:LISTEN" to detect if it's up before exit


This script, right?


 nohup "$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" 
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1 < /dev/null 
&
if [ $? -eq 0 ]


Now, this script

 - Runs the process using nohup
 - Merges stderr with stdout
 - Forks directly on start.
 - Uses a bash parent as pid.

Nothing of this makes systemd's task simpler. Personally, I'd consider 
three routes:


 - If the socket availability doesn't matter, remove the nohup, 
redirection, fork stuff and use a "Type = simple" service. Presuming 
that the java process runs in foreground this should be fine.


 - If the java process runs in background anyway, it could be fixed by 
teaching it to write a pidfile (-> Type = forking). This should be a 
simple fix  which could be upstreamed.


 - If you need to socket(s) to be available and type = forking doesn't 
make it (exits parent to early, doesn't fork) the code should be fixed 
by teaching it to issue a sd_notify (-> Type = notify).


Just my 5 öre.


Cheers!

--alec


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

>  - If the socket availability doesn't matter, remove the nohup,
redirection, fork stuff and use a "Type = simple" service. Presuming that
the java process runs in foreground this should be fine.

passing -f to solr or start-foreground to zookeeper would short-circuit the
"nohup" as it would use "exec java blah blah" like this

start-foreground)
ZOO_CMD=(exec "$JAVA")
"${ZOO_CMD[@]}" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \

which is my preferred way

> - If the java process runs in background anyway,

no it's not. ZK's java process is a foreground process

> - If you need to socket(s) to be available and type = forking doesn't
make it (exits parent to early, doesn't fork) the code should be fixed by
teaching it to issue a sd_notify (-> Type = notify).

can we do this using some "side" command like "ExecStartPost="
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

upstream issue < https://issues.apache.org/jira/browse/ZOOKEEPER-2095

suggests the following

ExecStart=/usr/bin/java \
  -Dzookeeper.log.dir=/var/log/zookeeper \
  -Dzookeeper.root.logger=INFO,ROLLINGFILE \
  -cp /usr/share/java/zookeeper/* \
  -Dlog4j.configuration=file:/etc/zookeeper/log4j.properties \
  -Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.local.only=false \
  org.apache.zookeeper.server.quorum.QuorumPeerMain \
   /etc/zookeeper/zoo.cfg

and it's seems that this is accepted in their SVN (against trunk revision
1685685)




On Tue, Jan 12, 2016 at 2:44 PM, Muayyad AlSadi  wrote:

> >  - If the socket availability doesn't matter, remove the nohup,
> redirection, fork stuff and use a "Type = simple" service. Presuming that
> the java process runs in foreground this should be fine.
>
> passing -f to solr or start-foreground to zookeeper would short-circuit
> the "nohup" as it would use "exec java blah blah" like this
>
> start-foreground)
> ZOO_CMD=(exec "$JAVA")
> "${ZOO_CMD[@]}" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
> "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
>
> which is my preferred way
>
> > - If the java process runs in background anyway,
>
> no it's not. ZK's java process is a foreground process
>
> > - If you need to socket(s) to be available and type = forking doesn't
> make it (exits parent to early, doesn't fork) the code should be fixed by
> teaching it to issue a sd_notify (-> Type = notify).
>
> can we do this using some "side" command like "ExecStartPost="
>
>
>
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Alec Leamas]

On 12/01/16 19:33, Muayyad AlSadi wrote:

Will I do agree it's a hack.
But it's better than forking in bash.

And usually I don't care about the exact time socket/port is active
because zookeeper is supposed to handle fail over.


[ the rest below..]


Please don't top-post [1]

Cheers!

--alec

[1] https://fedoraproject.org/wiki/Mailing_list_guidelines
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Reindl Harald]

Am 12.01.2016 um 19:30 schrieb Lennart Poettering:

On Tue, 12.01.16 18:54, Reindl Harald (h.rei...@thelounge.net) wrote:


Also, what happens if the daemon is configured to listen on some
different port? Or on multiple ports? Are you parsing the daemon's
config file too to figure out what to watch for? YUCK!


the Fedora myqld unit does, mine is simplified

the systemd-behavior that manual "systemctl stop whatever.service" don't
prevent socket activation and fireup again the service is a systemd problem
*you* have to solve if you want widely adopted usage of socket activation


That's hardly a "problem", as I see it.


for you


What you should be invoking is "systemctl stop whatever.socket
whatever.service", which terminates both the daemon and the listening
socket. I think that's pretty easy to grok for most folks, as long as
you realized the logic behind it once.


it's not a matter of grok something

it's a matter of not every daemon has a socket and hwat does the user 
express with a command - you aregued the same way about making 
"systemctl stop sshd" versus "systemctl stop sshd.service" work as default



That said, of course, this is not obvious at first, hence since quite
some time "systemctl stop" will actually explain this to you: if you
stop a daemon, but leave its socket running, then you'll get a
friendly message telling you about this, and suggesting you the right
command line to terminate the socket too.


as soon as you are able to print out such a "friendly message" you are 
also able to imply it automatically



I am pretty sure this makes a lot of sense the way it is, and is
sufficiently well self-explanatory.


no, it violates the prnciple of least surprise and that won't change



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Reindl Harald]

Am 12.01.2016 um 19:44 schrieb Lennart Poettering:

On Tue, 12.01.16 19:37, Reindl Harald (h.rei...@thelounge.net) wrote:


That said, of course, this is not obvious at first, hence since quite
some time "systemctl stop" will actually explain this to you: if you
stop a daemon, but leave its socket running, then you'll get a
friendly message telling you about this, and suggesting you the right
command line to terminate the socket too.


as soon as you are able to print out such a "friendly message" you are also
able to imply it automatically


Well, sure, but that's something we don't want to do, as people should
be able to stop units and their triggering units separately and
individually.

I'd be willing to take a patch that adds a new job mode though, that
recursively includes stop/start jobs for all triggering
units. i.e. "systemctl --job-mode=triggering foo.service" or so. That
would certainly be a useful enhancement, but should not be the
default.


IT SHOULD be the default

when i say "systemctl stop service" i mean that unconditionally and 
there is no point in for example stop a webserver manually while the 
socket would fire up the service on the next request


there is *really* no point for such a behavior


I am pretty sure this makes a lot of sense the way it is, and is
sufficiently well self-explanatory.


no, it violates the prnciple of least surprise and that won't change


Well, let's agree to disagree on this one


well, than accept that i refuse to use socket activated services and 
recommend that to anybody else until bheavior changes




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Lennart Poettering]

On Tue, 12.01.16 18:54, Reindl Harald (h.rei...@thelounge.net) wrote:

> >Also, what happens if the daemon is configured to listen on some
> >different port? Or on multiple ports? Are you parsing the daemon's
> >config file too to figure out what to watch for? YUCK!
> 
> the Fedora myqld unit does, mine is simplified
> 
> the systemd-behavior that manual "systemctl stop whatever.service" don't
> prevent socket activation and fireup again the service is a systemd problem
> *you* have to solve if you want widely adopted usage of socket activation

That's hardly a "problem", as I see it. 

What you should be invoking is "systemctl stop whatever.socket
whatever.service", which terminates both the daemon and the listening
socket. I think that's pretty easy to grok for most folks, as long as
you realized the logic behind it once.

That said, of course, this is not obvious at first, hence since quite
some time "systemctl stop" will actually explain this to you: if you
stop a daemon, but leave its socket running, then you'll get a
friendly message telling you about this, and suggesting you the right
command line to terminate the socket too.

I am pretty sure this makes a lot of sense the way it is, and is
sufficiently well self-explanatory.

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Lennart Poettering]

On Tue, 12.01.16 19:48, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 12.01.2016 um 19:44 schrieb Lennart Poettering:
> >On Tue, 12.01.16 19:37, Reindl Harald (h.rei...@thelounge.net) wrote:
> >
> >>>That said, of course, this is not obvious at first, hence since quite
> >>>some time "systemctl stop" will actually explain this to you: if you
> >>>stop a daemon, but leave its socket running, then you'll get a
> >>>friendly message telling you about this, and suggesting you the right
> >>>command line to terminate the socket too.
> >>
> >>as soon as you are able to print out such a "friendly message" you are also
> >>able to imply it automatically
> >
> >Well, sure, but that's something we don't want to do, as people should
> >be able to stop units and their triggering units separately and
> >individually.
> >
> >I'd be willing to take a patch that adds a new job mode though, that
> >recursively includes stop/start jobs for all triggering
> >units. i.e. "systemctl --job-mode=triggering foo.service" or so. That
> >would certainly be a useful enhancement, but should not be the
> >default.
> 
> IT SHOULD be the default

Well, no. And spelling this out in caps won't help.

This is nothing we can just change, even if we'd want to. It's exposed
stable behaviour.

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

Should we split the discussion about socket activation in another thread.

And discuss zookeeper service specifically here.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Lennart Poettering]

On Tue, 12.01.16 19:37, Reindl Harald (h.rei...@thelounge.net) wrote:

> >That said, of course, this is not obvious at first, hence since quite
> >some time "systemctl stop" will actually explain this to you: if you
> >stop a daemon, but leave its socket running, then you'll get a
> >friendly message telling you about this, and suggesting you the right
> >command line to terminate the socket too.
> 
> as soon as you are able to print out such a "friendly message" you are also
> able to imply it automatically

Well, sure, but that's something we don't want to do, as people should
be able to stop units and their triggering units separately and
individually.

I'd be willing to take a patch that adds a new job mode though, that
recursively includes stop/start jobs for all triggering
units. i.e. "systemctl --job-mode=triggering foo.service" or so. That
would certainly be a useful enhancement, but should not be the
default.

> >I am pretty sure this makes a lot of sense the way it is, and is
> >sufficiently well self-explanatory.
> 
> no, it violates the prnciple of least surprise and that won't change

Well, let's agree to disagree on this one.

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

>
> Please don't top-post [1]
>

Sorry I was on mobile gmail client.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Reindl Harald]

Am 12.01.2016 um 17:41 schrieb Lennart Poettering:

On Tue, 12.01.16 17:16, Muayyad AlSadi (als...@gmail.com) wrote:


well. But if you can double fork() in Java you should be fine and can


it seems that zookeeper is doing the fork in the bash script using nohub
not in java


when it finished setting up its listening socket. You cannot script


typically I loop using "lsof" or "nc"


Such sleep loops are ugly and a hack. It would be much better to fix
this properly with a clean notification.

Doing such sleep loops will just help keeping up java's bad rep for
being slow...

Also, what happens if the daemon is configured to listen on some
different port? Or on multiple ports? Are you parsing the daemon's
config file too to figure out what to watch for? YUCK!


the Fedora myqld unit does, mine is simplified

the systemd-behavior that manual "systemctl stop whatever.service" don't 
prevent socket activation and fireup again the service is a systemd 
problem *you* have to solve if you want widely adopted usage of socket 
activation




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

Will I do agree it's a hack.
But it's better than forking in bash.

And usually I don't care about the exact time socket/port is active because
zookeeper is supposed to handle fail over.
On Jan 12, 2016 7:54 PM, "Reindl Harald"  wrote:

>
>
> Am 12.01.2016 um 17:41 schrieb Lennart Poettering:
>
>> On Tue, 12.01.16 17:16, Muayyad AlSadi (als...@gmail.com) wrote:
>>
>> well. But if you can double fork() in Java you should be fine and can

>>>
>>> it seems that zookeeper is doing the fork in the bash script using nohub
>>> not in java
>>>
>>> when it finished setting up its listening socket. You cannot script

>>>
>>> typically I loop using "lsof" or "nc"
>>>
>>
>> Such sleep loops are ugly and a hack. It would be much better to fix
>> this properly with a clean notification.
>>
>> Doing such sleep loops will just help keeping up java's bad rep for
>> being slow...
>>
>> Also, what happens if the daemon is configured to listen on some
>> different port? Or on multiple ports? Are you parsing the daemon's
>> config file too to figure out what to watch for? YUCK!
>>
>
> the Fedora myqld unit does, mine is simplified
>
> the systemd-behavior that manual "systemctl stop whatever.service" don't
> prevent socket activation and fireup again the service is a systemd problem
> *you* have to solve if you want widely adopted usage of socket activation
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Reindl Harald]

Am 12.01.2016 um 19:50 schrieb Lennart Poettering:

On Tue, 12.01.16 19:48, Reindl Harald (h.rei...@thelounge.net) wrote:




Am 12.01.2016 um 19:44 schrieb Lennart Poettering:

On Tue, 12.01.16 19:37, Reindl Harald (h.rei...@thelounge.net) wrote:


That said, of course, this is not obvious at first, hence since quite
some time "systemctl stop" will actually explain this to you: if you
stop a daemon, but leave its socket running, then you'll get a
friendly message telling you about this, and suggesting you the right
command line to terminate the socket too.


as soon as you are able to print out such a "friendly message" you are also
able to imply it automatically


Well, sure, but that's something we don't want to do, as people should
be able to stop units and their triggering units separately and
individually.

I'd be willing to take a patch that adds a new job mode though, that
recursively includes stop/start jobs for all triggering
units. i.e. "systemctl --job-mode=triggering foo.service" or so. That
would certainly be a useful enhancement, but should not be the
default.


IT SHOULD be the default


Well, no. And spelling this out in caps won't help.

This is nothing we can just change, even if we'd want to. It's exposed
stable behaviour.

Sorry


surely, you could in systemd recognize that the socket is ignored for 
now, automatically started with the next "systemctl start service"


there is a huge difference between

* socket enabled, service not running
* socket enabled, service stopped by the admin

in case 1 it's exposed behavior to start the service on the first 
request, in case 2 it's the explicit wish of the admin SHUT DOWN a 
service - with the still enabled and listening socket that wish is worth 
*nothing* because there is no difference between a running netwrok 
waware service or a stopped one with a listening socket fire it up by 
the first request


"systemctl stop service" in fact does *nothing*

what makes that beavior worst is that "systemctl stop service.service 
service.socket" enorces the admin not just start the service after 
maintain operatins - he needs also to start the socket


a "systemctl stop service" with implicit stop the socket and after 
maintainence "systemctl start service" autmatically start the socket if 
it was implicit stopped would be the desired behavior for anybody in 
real life




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Lennart Poettering]

On Mon, 11.01.16 20:19, Christopher (ctubbsii-fed...@apache.org) wrote:

> 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?

I am not a Java programmer, so I don't really know how Java works that
well. But if you can double fork() in Java you should be fine and can
implement correct Type=forking (i.e. SysV) semantics, but I have the
suspicion that Java doesn't really permit the concept of fork()...

Alternatively, you could implement Type=notify semantics, i.e
implement in Java the equivalent of sd_notify(). It's trivial
actually, you just send a single AF_UNIX/SOCK_DGRAM datagram with a
newline separated string to the socket specified in
$NOTIFY_SOCKET. See the NOTES section in sd_notify(3) about this. That
said, I have the suspicion that Java might not allow you to use
AF_UNIX/SOCK_DGRAM sockets, either?

If that's the case, then you could add a trivial JNI wrapper around
the C routine that is sd_notify(), and get Type=notify semantics that
way...

I think there's also this:

  https://commons.apache.org/proper/commons-daemon/

Not sure how current this is, but it might get you Type=forking
semantics too. But I have no idea what this really does, it could be
that it's not actually really implementing proper UNIX semantics...

> 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?

You cannot really implement the double-forking concept with shell
scripts only. Also, and most importantly you really need some kind of
notification concept to indicate completion of initialization. That
can either be sd_notify() for Type=notify mode, or something
internal+exit() in the parent for Type=forking mode, but it must be
something.

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Lennart Poettering]

On Tue, 12.01.16 15:57, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 12.01.2016 um 15:45 schrieb Lennart Poettering:
> >On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote:
> >
> >>
> >>@Lennart Poettering is there a way to use something like "ExecStartPost="
> >>do the the notify with type=simple?
> >
> >When would you even call that? Somehow your Java app needs to report
> >when it finished setting up its listening socket. You cannot script
> >around that fact
> 
> at the same point as for mariadb /  mysql

...
>  usleep 10
...

Polling around a 1s sleep loop. That's a gross hack.

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Lennart Poettering]

On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote:

> 
> @Lennart Poettering is there a way to use something like "ExecStartPost="
> do the the notify with type=simple?

When would you even call that? Somehow your Java app needs to report
when it finished setting up its listening socket. You cannot script
around that fact.

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Reindl Harald]

Am 12.01.2016 um 16:09 schrieb Lennart Poettering:

On Tue, 12.01.16 15:57, Reindl Harald (h.rei...@thelounge.net) wrote:



Am 12.01.2016 um 15:45 schrieb Lennart Poettering:

On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote:



@Lennart Poettering is there a way to use something like "ExecStartPost="
do the the notify with type=simple?


When would you even call that? Somehow your Java app needs to report
when it finished setting up its listening socket. You cannot script
around that fact


at the same point as for mariadb /  mysql


...

  usleep 10

...

Polling around a 1s sleep loop. That's a gross hack


besides that 10 us are hardly a second (the fedora build afaik is 
using a sleep 1) it works the last 5 years perfectly and "You cannot 
script around that fact" is wrong if you like it or not






signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

> well. But if you can double fork() in Java you should be fine and can

it seems that zookeeper is doing the fork in the bash script using nohub
not in java

> when it finished setting up its listening socket. You cannot script

typically I loop using "lsof" or "nc"

> Polling around a 1s sleep loop. That's a gross hack.

usually I use loop i over `seq XYZ` and sleep increasing amount (I start
sleep with 0.1s then 0.2s then 0.3 ...) then give up
and there is no initial wait

bash -c "for i in `seq 1000 10 1000`; do echo '' | nc localhost $PORT
1>/dev/null 2>/dev/null && echo $PORT is up && break; usleep $i; done"

> at the same point as for mariadb /  mysql

thank you this is what I'm talking about





On Tue, Jan 12, 2016 at 4:45 PM, Lennart Poettering 
wrote:

> On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote:
>
> >
> > @Lennart Poettering is there a way to use something like "ExecStartPost="
> > do the the notify with type=simple?
>
> When would you even call that? Somehow your Java app needs to report
> when it finished setting up its listening socket. You cannot script
> around that fact.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

> Polling around a 1s sleep loop. That's a gross hack

that's 0.1s

On Tue, Jan 12, 2016 at 5:15 PM, Reindl Harald 
wrote:

>
>
> Am 12.01.2016 um 16:09 schrieb Lennart Poettering:
>
>> On Tue, 12.01.16 15:57, Reindl Harald (h.rei...@thelounge.net) wrote:
>>
>>
>>> Am 12.01.2016 um 15:45 schrieb Lennart Poettering:
>>>
 On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote:


> @Lennart Poettering is there a way to use something like
> "ExecStartPost="
> do the the notify with type=simple?
>

 When would you even call that? Somehow your Java app needs to report
 when it finished setting up its listening socket. You cannot script
 around that fact

>>>
>>> at the same point as for mariadb /  mysql
>>>
>>
>> ...
>>
>>>   usleep 10
>>>
>> ...
>>
>> Polling around a 1s sleep loop. That's a gross hack
>>
>
> besides that 10 us are hardly a second (the fedora build afaik is
> using a sleep 1) it works the last 5 years perfectly and "You cannot script
> around that fact" is wrong if you like it or not
>
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Lennart Poettering]

On Tue, 12.01.16 17:16, Muayyad AlSadi (als...@gmail.com) wrote:

> > well. But if you can double fork() in Java you should be fine and can
> 
> it seems that zookeeper is doing the fork in the bash script using nohub
> not in java
> 
> > when it finished setting up its listening socket. You cannot script
> 
> typically I loop using "lsof" or "nc"

Such sleep loops are ugly and a hack. It would be much better to fix
this properly with a clean notification.

Doing such sleep loops will just help keeping up java's bad rep for
being slow...

Also, what happens if the daemon is configured to listen on some
different port? Or on multiple ports? Are you parsing the daemon's
config file too to figure out what to watch for? YUCK!

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Alec Leamas]

On 11/01/16 21:19, Christopher wrote:


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?



What about a simple JNI wrapper to sd_notify(3)? Shouldn't be hard, 
gives the process a chance to actually signal when its' ready.


Cheers!

--alec

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Christopher]

On Mon, Jan 11, 2016 at 11:41 AM Lennart Poettering 
wrote:

> On Mon, 11.01.16 18:30, Muayyad AlSadi (als...@gmail.com) 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@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Reindl Harald]

Am 11.01.2016 um 14:06 schrieb Muayyad AlSadi:

hi,

in fedora's zookeeper service < /usr/lib/systemd/system/zookeeper.service
we have the following line

ExecStart=/usr/bin/zkServer.sh start zoo.cfg

why not

ExecStart=/usr/bin/zkServer.sh start-foreground zoo.cfg

of type simple

specially that file does not contain "PIDFile=" directive


type simple don't come without drawbacks
depending service shave *no idea* if it is ready

the "clamd" service as example comes with "Type = simple" which means 
when you are using clamav-milter you get at boot a ton of warnings while 
"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)




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/11/2016 08:06 AM, Muayyad AlSadi wrote:
> hi,
> 
> in fedora's zookeeper service <
> /usr/lib/systemd/system/zookeeper.service we have the following
> line
> 
> ExecStart=/usr/bin/zkServer.sh start zoo.cfg
> 
> why not
> 
> ExecStart=/usr/bin/zkServer.sh start-foreground zoo.cfg
> 
> of type simple
> 
> specially that file does not contain "PIDFile=" directive

Probably best to direct that question at the package maintainer(s)
(I've CCed them now)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlaTrCYACgkQeiVVYja6o6OLdgCfXuUstmk5bbtruQFBgZDyEtwz
DhcAn1NEJ6DMMTccaMVcpc/6UcX9HSK2
=dAuF
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

> "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)



On Mon, Jan 11, 2016 at 3:18 PM, Reindl Harald 
wrote:

>
>
> Am 11.01.2016 um 14:06 schrieb Muayyad AlSadi:
>
>> hi,
>>
>> in fedora's zookeeper service < /usr/lib/systemd/system/zookeeper.service
>> we have the following line
>>
>> ExecStart=/usr/bin/zkServer.sh start zoo.cfg
>>
>> why not
>>
>> ExecStart=/usr/bin/zkServer.sh start-foreground zoo.cfg
>>
>> of type simple
>>
>> specially that file does not contain "PIDFile=" directive
>>
>
> type simple don't come without drawbacks
> depending service shave *no idea* if it is ready
>
> the "clamd" service as example comes with "Type = simple" which means when
> you are using clamav-milter you get at boot a ton of warnings while
> "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)
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Reindl Harald]

Am 11.01.2016 um 14:32 schrieb Muayyad AlSadi:

"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


*nothing* needs a PID file path because systemd knows the main-PID since 
it's a supervisor - in fact for most services throwing warnings because 
the pid-file the solotuin from F15 until now was clone the systemd-unit 
below /etc/systemd/system/ and remove the line



[root@mail-gw:~]$ systemd-analyze blame | grep clamd
 10.750s clamd.service


[root@mail-gw:~]$ systemctl status clamd
  clamd.service - ClamAV Scanner Daemon
   Loaded: loaded (/etc/systemd/system/clamd.service; enabled; vendor 
preset: disabled)
   Active: active (running) since Di 2015-12-22 12:40:33 CET; 2 weeks 6 
days ago

 Main PID: 5402 (clamd)
   CGroup: /system.slice/clamd.service
   ??5402 /usr/sbin/clamd -c /etc/clamd.d/scan.conf


[root@mail-gw:~]$ cat /etc/systemd/system/clamd.service
[Unit]
Description=ClamAV Scanner Daemon

[Service]
Type=forking
Environment="TMPDIR=/tmp"
Environment="LANG=en_GB.UTF-8"
ExecStart=/usr/sbin/clamd -c /etc/clamd.d/scan.conf
ExecReload=/usr/bin/kill -HUP $MAINPID
Restart=always
RestartSec=1
Nice=5

User=clamscan
Group=clamilt

PrivateTmp=yes
PrivateDevices=yes
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_KILL
RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 AF_IPX 
AF_NETLINK AF_PACKET AF_X25

SystemCallArchitectures=x86-64

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var/lib



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

hi,

in fedora's zookeeper service < /usr/lib/systemd/system/zookeeper.service
we have the following line

ExecStart=/usr/bin/zkServer.sh start zoo.cfg

why not

ExecStart=/usr/bin/zkServer.sh start-foreground zoo.cfg

of type simple

specially that file does not contain "PIDFile=" directive
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Lennart Poettering]

On Mon, 11.01.16 18:30, Muayyad AlSadi (als...@gmail.com) 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

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Reindl Harald]

Am 11.01.2016 um 15:37 schrieb Michal Schmidt:

On 01/11/2016 02:58 PM, Reindl Harald wrote:

Am 11.01.2016 um 14:32 schrieb Muayyad AlSadi:

"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


*nothing* needs a PID file path because systemd knows the main-PID
since it's a supervisor


systemd cannot always guess which PID is the main PID of the service,
so with Type=forking it's good to use PIDFile=


every service in the last years which logged warnings about PIDFile 
while working fine was fixed here by remove that line


the main PID is the PID after the double-fork



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Michal Schmidt]

On 01/11/2016 03:48 PM, Reindl Harald wrote:
> Am 11.01.2016 um 15:37 schrieb Michal Schmidt:
>> On 01/11/2016 02:58 PM, Reindl Harald wrote:
>>> *nothing* needs a PID file path because systemd knows the main-PID
>>> since it's a supervisor
>>
>> systemd cannot always guess which PID is the main PID of the service,
>> so with Type=forking it's good to use PIDFile=
> 
> every service in the last years which logged warnings about PIDFile
> while working fine was fixed here by remove that line

Good for you.

> the main PID is the PID after the double-fork

Some programs exit() the original process immediately after the first
fork(). Then it's possible for systemd to observe the first child and
assume it is the main PID. That's bad because that process is going to
go away after forking the second time.

Michal
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Muayyad AlSadi]

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

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 
wrote:

> On Mon, 11.01.16 15:32, Muayyad AlSadi (als...@gmail.com) 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@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Reindl Harald]

Am 11.01.2016 um 17:30 schrieb Muayyad AlSadi:

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


is that just guessing or proven?




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Michal Schmidt]

On 01/11/2016 02:58 PM, Reindl Harald wrote:
> Am 11.01.2016 um 14:32 schrieb Muayyad AlSadi:
>>> "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
> 
> *nothing* needs a PID file path because systemd knows the main-PID
> since it's a supervisor

systemd cannot always guess which PID is the main PID of the service,
so with Type=forking it's good to use PIDFile=.

Michal
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Lennart Poettering]

On Mon, 11.01.16 15:32, Muayyad AlSadi (als...@gmail.com) 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@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org