[arch-general] Forking daemons and systemd

[Dave Reisner]

On Mon, Nov 05, 2012 at 02:37:15PM -0600, Leonid Isaev wrote:
> On Mon, 5 Nov 2012 11:18:48 -0500
> Dave Reisner <d at falconindy.com> wrote:
> 
> > 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
> 
> Aha... thanks for the clarification. I'm pretty sure that havege does not
> open any sockets/has to be a dependency of anything, but ntpd I'll have to
> check.

It isn't just side effects which are a concern -- it might be the
facility being provided that you want to wait on. Using part of your own
example, you might not want to start your mail daemon before ntpd has
run, to ensure proper timestamping. There's even a 'time-sync.target'
documented by systemd.special(7) which one might want to order on,
making ntpd's startup more important.

d