Re: is there a reason for starting zookeeper.service in background?
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?
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?
> > 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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
> 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?
> 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?
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?
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?
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 [Service] Type=simple User=mysql Group=mysql ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/dev/null ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID _ [root@rh:~]$ cat /usr/libexec/mysqld-wait-ready #!/usr/bin/bash # Service file passes us the daemon's PID daemon_pid="$1" # Wait for the server to come up or for the mysqld process to disappear ret=0 while /usr/bin/true; do RESPONSE=`/usr/bin/mysqladmin --defaults-file=/etc/my.cnf --socket=/var/lib/mysql/mysql.sock --user=UNKNOWN_MYSQL_USER ping 2>&1` mret=$? if [ $mret -eq 0 ]; then break fi # exit codes 1, 11 (EXIT_CANNOT_CONNECT_TO_SERVICE) are expected, # anything else suggests a configuration error if [ $mret -ne 1 -a $mret -ne 11 ]; then ret=1 break fi # "Access denied" also means the server is alive echo "$RESPONSE" | grep -q "Access denied for user" && break # Check process still exists if ! /usr/bin/kill -0 $daemon_pid 2>/dev/null; then ret=1 break fi usleep 10 done exit $ret 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?
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?
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?
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?
> - 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?
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?
> 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?
> 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?
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?
>> 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?
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?
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?
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?
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?
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?
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
Re: is there a reason for starting zookeeper.service in background?
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?
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?
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?
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
Re: is there a reason for starting zookeeper.service in background?
> "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?
-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?
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
is there a reason for starting zookeeper.service in background?
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