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

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

Daniel Kahn Gillmor:
The implication of this  proposed GR seems to be that those tools
> would be unfit for inclusion within debian unless someone erects all
> the additional scaffolding that runit provides (process supervision,
> pipelined logfiles with autorotation and log msgs just sent to
> stderr, restart on abnormal termination, no need for daemonization,
> clean process initialization, etc), but does so outside of runit.

Ian Jackson:
But runit is exactly the  scaffolding needed to do that, and already
> exists! runit can coexist peacefully with sysvinit, systemd,
> upstart, or whatever. There is no problem depending on runit because
> runit doesn't demand being pid 1, so it is nonexclusive.

Daniel Kahn Gillmor:
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.

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

Daniel Kahn Gillmor:
Consider a tool that integrates  in some way with /etc/runit/1 or
> /etc/runit/2 or /etc/runit/3, which are only relevant for systems
> with runit as pid 1 (see runit(8) for more details). Such a tool
> should not be RC-buggy just because it's useless on a system that
> uses systemd or sysvinit.

Perhaps if you picked something other than runit you'd make your point more effectively. Try using the case of someone who makes a tool that depends from System V init running as process #1. It is hardly farfetched. I've seen at least two people publicly point out in the past several months that they had something set up in /etc/inittab that broke when they switched to an alternative bootstrap system. (A lot of people conflate "init" with "rc". It's not System V init that other bootstrap systems sometimes provide shims and compatibility mechanisms for. It's System V rc, more specifically the /etc/rc?.d/* scripts that it runs.) There's also a Debian bug or two. So the question that you should be asking to make your point is probably this: The resolution says that "In general, software may not require a specific init system to be pid 1.". Does this mean that softwares that make use of /etc/inittab, which is peculiar to (in Ian Jackson's own words) "a specific init system" (its contents, outwith sometimes the run level line, being not processed at all by any of upstart, systemd, runit-init, s6-svscan, the nosh system or service managers, minit, jinit, or finit), are unfit for inclusion in Debian according to Ian Jackson's resolution?

* https://lists.debian.org/debian-vote/2014/03/msg00103.html
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747742

Requiring that people be bootstrap system neutral has perhaps unintended consequences, one of which is disappointing the spectators (in the press and on other mailing lists) who mistakenly thought that M. Jackson was championing the System V init status quo ante. Proper neutrality, it turns out once one sits down and actually looks at it, makes work for the maintainers of old softwares that only work with System V init, too. M. Jackson, perhaps unintentionally, is pushing in the final nail in the coffin of /etc/inittab . (-:

Reply to: