Re: [arch-general] Forking daemons and systemd
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/
Re: [arch-general] Forking daemons and systemd
Am 06.11.2012 02:22, schrieb ianux: 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 ? I'd say yes. In practice, you should just try it, and if any bugs appear see if Type=simple is the problem. signature.asc Description: OpenPGP digital signature
[arch-general] Forking daemons and systemd
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)? TIA, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Forking daemons and systemd
On Mon, Nov 5, 2012 at 5:01 PM, Leonid Isaev lis...@umail.iu.edu wrote: 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? If you start the daemon in the foreground (i.e., use the default Type=simple), it means that systemd will consider it started immediately, and not wait for it to be initialized. In other words, it assumes that whatever communication channels (sockets) have been set up already and that the daemon supports being socket activated. If that is not the case, then services which are ordered after your service might start too early. Clearly, if you know that nothing will ever be ordered After= your service the above is not an issue, and you can use Type=simple without worrying. A better solution would be to patch the service to support Type=dbus/notify or to support socket activation. If that is out of the question, then Type=forking is the safest bet. This mode is a bit more fragile than the other ones, as it relies on systemd being able to figure out what is the main process. Specifying PIDFile= is advised if the daemon supports that. Though it depends on the daemon implementing that correctly. Most (all?) it works just fine :-) HTH, Tom
Re: [arch-general] Forking daemons and systemd
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
Re: [arch-general] Forking daemons and systemd
On Mon, 5 Nov 2012 11:18:48 -0500 Dave Reisner d...@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. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Forking daemons and systemd
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...@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
Re: [arch-general] Forking daemons and systemd
I used type=forking in my espeakup unit. From what I'm reading, it looks like that was actually unnecessary, since a. espeakup is not a dependency of any other service, as it only provides speech feedback for blind users at boot time, and b. the daemon supports a pidfile, which I included in the service unit. I can test this on my local unit file, or I can pull the edited version from testing to be sure it works correctly in most if not all cases. ~Kyle http://kyle.tk -- Linux killed Kenny, bastard! --Subject of a real e-mail to the Linux kernel mailing list 12 January, 2009
Re: [arch-general] Forking daemons and systemd
On Mon, Nov 5, 2012 at 10:48 PM, Kyle k...@gmx.ca wrote: a. espeakup is not a dependency of any other service, as it only provides speech feedback for blind users at boot time, and b. the daemon supports a pidfile, which I included in the service unit. I can test this on my local unit file, or I can pull the edited version from testing to be sure it works correctly in most if not all cases. I think in this case it makes sense to use Type=forking (especially as there is a PIDFile, so this will likely work well). I can imagine wanting to start something only after espeakup is up, even if that is not the case at the moment. -t
Re: [arch-general] Forking daemons and systemd
According to Tom Gundersen: # I think in this case it makes sense to use Type=forking (especially as # there is a PIDFile, so this will likely work well). I can imagine # wanting to start something only after espeakup is up, even if that is # not the case at the moment. Oh, so forking wasn't the issue with my file, only the location of the pidfile. I see I somehow forgot about the change from /var/run to /run. I guess I didn't catch it when I copied its location from the initscript. I'll run a test, as I now have the new file, but I see no reason why it wouldn't be usable or work as expected. Sorry I wasn't able to test sooner, as I had other things going on over the past week. ~Kyle http://kyle.tk -- Linux killed Kenny, bastard! --Subject of a real e-mail to the Linux kernel mailing list 12 January, 2009
Re: [arch-general] Forking daemons and systemd
According to Kyle: # I'll run a test, as I now have the new file, but I see no reason why it # wouldn't be usable or work as expected. Tested and it works perfectly. Thanks for getting this in, and sorry for taking this thread for a little bit of a ride into the land of OT. ~Kyle http://kyle.tk -- Linux killed Kenny, bastard! --Subject of a real e-mail to the Linux kernel mailing list 12 January, 2009
