On Wed, 19.04.17 20:32, Andrei Borzenkov (arvidj...@gmail.com) wrote: > 18.04.2017 21:35, Jonathan de Boyne Pollard пишет: > > "Igal @ Lucee.org" <i...@lucee.org>: > >> Examples I see online use forking [...] > > > > ... because they are bad examples. Read > > http://jdebp.eu./FGA/systemd-house-of-horror/tomcat.html . > > Service type simple is the worst possible type as it does not provide > for any synchronization between started process and dependent services. > So examples that recommend forking are correct (as long as forking is > implemented correctly). If you have choice between working forking and > simple, forking is definitely preferred.
I can only second that. The various types in order of preference: 1) Type=notify — if the daemon supports that this is almost always the best option, as no forking and no messy PID files are involved, and proper ready synchronization is supported. Of course, the daemons need to support this method explicitly. Supporting this is easy though: you can either use libsystemd's sd_notify() function or any similar library for your language of choice. In fact, the underlying protocol is so simple and generic, that it is trivial to reimplement without involving any external library altogether: simply send a single AF_UNIX/SOCK_DGRAM datagram to the socket set in $NOTIFY_SOCKET containing a newline-separated text string and you are done. (There's one trick though: if $NOTIFY_SOCKET starts with an '@' character, it refers to a socket in the Linux AF_UNIX 'abstract' namespace, which essentially means you need to replace it with a NUL char when binding). 2) Type=forking — this is the traditional UNIX way. It requires double-fork()ing in order to daemonize. If your daemon consists of multiple processes your daemon also needs to write out a PID file (and you need to tell systemd about it via PIDFile=), otherwise systemd can't know which the 'main' process of your daemon is. Double-fork()ing correctly is hard, and traditionally people haven't been very good at implementing this correctly. Well-known mistakes are: people only fork() once, not twice, which means the process won't be reparented to PID 1 correctly — systemd is very forgiving on this one though. More problematic is if daemons exit in the parent process before the grandchild properly completed initialization and established all listening sockets and suchlike. For broken daemons like that startup synchronization won't work, as systemd will continue starting the next daemons at a time where these daemons haven't finished start-up yet. Note that not implementing this correctly not only is broken on systemd but also on all other init systems, including traditional SysV. Note that Type=forking is hard to use in programming environments where fork() is not available. Specifically, Go, Java, and many other higher-level programming languages don't really support fork() without execve(), i.e. they don't permit the language runtime being duplicated without all associated threads. 3) Type=simple — in this mode, systemd won't do any synchronization, and just fork off your daemon and immediately proceed with the next. This is a great option for daemons which are unlikely to fail or where failure shall not be propagated to any depending services. This is a particularly good option for socket activated services, as for them all communication channels are already established before the service starts, and synchronization is hence redundant. Type=simple is not a useful option however, if your daemon has a startup phase where it establishes communication channels or if it can likely fail during its startup phase and that fact should propagated to depending services. Under the assumption that Tomcat does have communication channels (most non-trivial software has) and there are depending services that need to wait for them to be established, and given that Tomcat appears to be written in Java, I am pretty sure Type=notify is the best option, but it does require sending out that notification message with sd_notify() or something equivalent. Given that systemd is pretty universally adopted in bigger distributions, in particular commercial ones these days, it should not be impossible to convince the Tomcat developers to add native support for the sd_notify() message. In particular as support for it is entirely transparent: if $NOTIFY_SOCKET is set, send that one ready message to it, otherwise don't. This will make things work nicely with systemd, and won't affect systems not using it. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel