Bug#727708: requirement of non-forking startup protocol
On Thu, Jan 02, 2014 at 10:04:12PM +0000, Ian Jackson wrote:
> Zbigniew Jędrzejewski-Szmek writes ("Bug#727708: requirement of non-forking startup protocol"):
> > | 8. Policy rules for support for init systems must:
> > |
> > | (a) Specify the use of a non-forking startup protocol (for
> > | upstart and systemd),
>
> [ Replying to this thread after a large glass of wine is probalby a
> bad idea, but this one seems OK I hope. Please forgive me if I'm
> incoherent or rude, although of osurse I'll try not to be. ]
In vino veritas :) Anyway, your mail seems fine :)
> > I'm not sure about upstart, but systemd is perfectly happy with
> > daemons which double fork (Type=forking in systemd parlance).
> > It is mildly discouraged, because:
> >
> > 1. it is hard to get right
> > 2. it is more code than the other options
> > 3. it is easier to start the program manually if non-forking protocol is used
>
> Am I right in thingking that this is what is described as "guess main
> pid" in the systemd documentation ? In which case it is indeed
> discouraged.
Not always. If PIDFile= is specified, than GuessMainPID is not necessary.
Also, if there just one process after initialization has finished (which
is normally true with double forking), "guessing" the main PID is trivial,
so GuessMainPID is also fine. So it's mainly GuessMainPID=true with a dameon
consisting of multiple processes that is discouraged.
> > For new code, other protocols are certainly better. But for existing
> > daemons which work correctly, points 1 and 2 don't matter, and 3 is not
> > important enough.
>
> I think if we're going to the trouble of converting all of the init
> systems, we should do so once and have them use the best arrangements.
>
> > This requirement might force mantainers to modify some hairy
> > internals in the startup code of daemons to avoid double forking. This
> > seems pointless, as in most cases it wouldn't result in any noticable
> > difference in speed or behaviour or correctness.
>
> Does this actualy arise as a problem in practice ? I find it
> difficult to think of a case where it would but perhaps you know of
> one.
I don't have any examples. But as you yourself argued, changing both
the build system and the code and init system wrapper to add this
functionality *is* a bit of work. It's not too much work to do if
there's a reason for it, but in case of correctly working
double-forking daemons is see no reason. Multiplying it by all packages
in the archive to be converted I'd much rather see maintainers doing
things which have visible impact.
> > I think this should be changed to:
> >
> > | 8. Policy rules for support for init systems must:
> > |
> > | (a) Encourage the use of a non-forking startup protocol (for
> > | upstart and systemd),
>
> In the case of upstart the -forking startup protocols are difficult to
> implement portably so in that case I think we should definitely retain
> a prohibition.
>
> I'm less sure about the systemd version of the resolution.
Ah, yes. So for upstart the trade-offs are different and it must stay
as you drafted it originally.
Zbyszek
Reply to: