[arch-general] Forking daemons and systemd

ianux ianux at free.fr
Mon Nov 5 20:22:30 EST 2012

Le 05/11/12, Dave Reisner <d at falconindy.com> a écrit :

> 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

I commented a bug about this : https://bugs.archlinux.org/task/31309

Is it safe to assume that if a daemon is meant to be run in
foreground (i.e default behaviour, without options) , it is safe to run
it this way in the corresponding service file ?

radio ianux - http://ianux.fr/

More information about the arch-general mailing list