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

Re: Re-Proposal - preserve freedom of choice of init systems

Daniel Kahn Gillmor writes ("Re: Re-Proposal - preserve freedom of choice of init systems"):
> nevertheless, runit behaves differently when it is pid 1 than when it is
> used in a subordinate role to another initsystem.  If i'm upstream and
> i'm building mechanisms that integrate with runit *as it behaves as pid
> 1*, the implication seems to be that my work would not be welcome in debian.

Are you saying that a daemon author would want to write code which
only worked if runit was pid 1 ?

This question of daemon startup is a red herring, I think.  It is
generally easy to solve the problem with some kind of wrapper or tool,
even if a daemon only starts up in a particular way.

> I like both postgresql and runit, and am really happy that both these
> things are in debian.  But postgresql isn't RC-buggy just because the
> system service doesn't start automatically when i choose to use runit as
> pid 1.

postgresql wouldn't be RC-buggy if it _never_ started automatically.
That would just be an annoying bug.

And the GR text is quite careful: it doesn't say that failure to work
with one init system is worse than any other bug.  It is only
_requiring a specific init system to be pid 1_ which is forbidden.

That's the exactly correct criterion because it is pid 1 which you can
only have one of.  A user can have as different non-pid-1 daemon
supervisors as they like so there is no problem with a daemon
requiring a particular supervisor - provided that supervisor can work
(well enough) when not pid 1.


Reply to: