[arch-general] Forking daemons and systemd

[Dave Reisner]

On Mon, Nov 05, 2012 at 10:01:11AM -0600, Leonid Isaev wrote:
> Hi,
> 
> 	I was wondering whether there is a guideline regarding using
> Type=forking daemons in systemd units. For instance, if a daemon supports a
> cmdline switch to run in foreground isn't it better to use this argument in
> ExecStart?
> 	Personally, I was bitten by this with haveged.service which fails on
> shutdown and whose unit has Type=forking, but I also noticed that ntpd is
> allowed to fork. Both of them support foreground operation (haveged -F and
> ntpd -n respectively)?

Essentially, it comes down to ordering of other daemons.

It's always going to be some trifling amount faster to start a daemon in
the foreground because systemd assumes it to be alive as soon as it
starts. Conversely, a Type=forking daemon is only considered alive only
once the parent process has exited.

What this means is that while you might be able to start a daemon which
normally forks in non-forking mode, you can't guarantee that daemons
which rely on the non-forking daemon can be reliably started, since
various listeners or other channels may not be established in time.

The ideal solution is to implement sd_notify() and use Type=notify, or
full blown socket activation should it be appropriate for the daemon.
Both of these cases allow for essentially fire-and-forget style startup
with guarantees of availability for ordering.

Of course, if you don't think you ever need to order anything on a given
daemon, then Type=simple is just fine.

HTH,
d