On Mon, 5 Nov 2012 11:18:48 -0500 Dave Reisner <d@xxxxxxxxxxxxxx> 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. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Attachment:
signature.asc
Description: PGP signature
