Am 11.01.2016 um 14:06 schrieb Muayyad AlSadi: 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)

Am 11.01.2016 um 14:32 schrieb Muayyad AlSadi: *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

Am 11.01.2016 um 15:37 schrieb Michal Schmidt: 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

On Mon, 11.01.16 15:32, Muayyad AlSadi (alsadi(a)gmail.com) wrote: 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

Am 11.01.2016 um 17:30 schrieb Muayyad AlSadi: is that just guessing or proven?

On Mon, Jan 11, 2016 at 11:41 AM Lennart Poettering <mzerqung(a)0pointer.de&gt; 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? 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?

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. 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) double-forking paradigm? 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. 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 <leamas.alec(a)gmail.com&gt; 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? >> >> > the process a chance to actually signal when its' ready. > > Cheers! > > --alec > > -- >> devel mailing list >> devel(a)lists.fedoraproject.org >> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org >> >> -- > devel mailing list > devel(a)lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org >

just pass "start-foreground" and it will be short-circuit

On 12/01/16 10:54, Muayyad AlSadi wrote: This script, right? 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

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 <alsadi(a)gmail.com&gt; wrote:

Am 12.01.2016 um 15:45 schrieb Lennart Poettering: 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 100000 done exit $ret

Am 12.01.2016 um 16:09 schrieb Lennart Poettering: besides that 100000 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

it seems that zookeeper is doing the fork in the bash script using nohub not in java typically I loop using "lsof" or "nc" 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 100000 1000`; do echo '' | nc localhost $PORT 1>/dev/null 2>/dev/null && echo $PORT is up && break; usleep $i; done" thank you this is what I'm talking about On Tue, Jan 12, 2016 at 4:45 PM, Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote: > On Tue, 12.01.16 10:22, Muayyad AlSadi (alsadi(a)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 > around that fact. > > Lennart > > -- > Lennart Poettering, Red Hat > -- > devel mailing list > devel(a)lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org >

Am 12.01.2016 um 17:41 schrieb Lennart Poettering: 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

Am 12.01.2016 um 19:30 schrieb Lennart Poettering: for you 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 as soon as you are able to print out such a "friendly message" you are also able to imply it automatically no, it violates the prnciple of least surprise and that won't change

Am 12.01.2016 um 19:44 schrieb Lennart Poettering: 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 well, than accept that i refuse to use socket activated services and recommend that to anybody else until bheavior changes

Am 12.01.2016 um 19:50 schrieb Lennart Poettering: 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

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" <h.reindl(a)thelounge.net&gt; wrote:

Sorry I was on mobile gmail client.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/11/2016 08:06 AM, Muayyad AlSadi wrote: 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-----