[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: requirement of non-forking startup protocol



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. ]

> 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.q

> 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 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.

Ian.


Reply to: