Le 05/11/12, Dave Reisner <d@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/