On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson <
[email protected]> wrote:
> Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
> > I have written a draft resolution from my own point of view and
> > checked it into the tech-ctte git repo. Perhaps some of it is useful.
> > Ansgar commented a bit on it on IRC. I guess I should post it.
>
> Here's my draft.
>
>
> Those who prefer systemd will want to s/upstart/systemd/ and vice
> versa, obviously. Aside from that:
>
> 0,3,4,5,8,10 are probably not very controversial (mutatis mutandi
> for those who prefer systemd).
>
> 2 (non-Linux ports) needs attention in the systemd case.
>
> 6 will not be controversial (mutatis mutandi) except:
>
> 6C (and the consequential paragraphs) may be quite controversial even
> amongst those who prefer upstart. This needs further discussion.
>
> 7 probably needs to deal with systemd too in any case; the
> corresponding feature is "guess main pid" I think.
>
> 9's usefulness was doubted by Russ, but I hope the substance at least
> is uncontroversial.
>
> 11 is probably going to be thought inappropriate but I wanted to at
> least float it.
>
> Of course some of you may want to take a completely different
> approach, perhaps specifying things in much less detail.
>
> For the "punt it to a GR" option, I don't think we should specify this
> level of detail about compatibility, policy, accepting patches etc.
> We should provide at least four draft ballot options (upstart,
> systemd, sysvinit, openrc) and request that the DPL propose the GR as
> the TC is too unweildy for handling amendments for something
> time-critical like this. The ballot options we suggest should all
> state that sysvinit is still mandatory to support in jessie.
>
> Thanks,
> Ian.
>
> | Rubric:
> |
> | 0. We decide as follows (Constitution 6.1(1),(2)). Text in square
> | brackets "[]" is non-binding advice (Constitution 6.1(5)). We
> | require the Policy Editors (Constitution 6.1(1)) to make the policy
> | changes they think appropriate to give effect to this resolution.
> |
> | Choice of init system:
> |
> | 1. The default init(1) in jessie will be upstart.
> |
> | 2. Architectures which do not currently support upstart should try to
> | port it. If this is not achieved in time, those architectures may
> | continue to use sysvinit. [ Non-use of upstart should not be a
> | criterion for architecture qualification status in jessie. ]
> |
> | 3. At least in jessie, unless a satisfactory compatibility approach is
> | developed and deployed (see paragraph 10), packages must continue
> | to provide sysvinit scripts. Lack of a sysvinit script (for a
> | daemon which contains integration with at least one other init
> | system) is an RC bug in jessie.
> |
> | [ After jessie, the policy editors may drop this requirement;
> | perhaps entirely, or perhaps in favour of a requirement to provide
> | at least one of sysvinit or systemd integration. The policy
> | editors may wish to refer this decision to us in due course. ]
> |
> | Policy is not ready, so hold off on updating all packages:
> |
> | 4. [ The current Debian policy for upstart, in the policy manual,
> | could do with some improvement and enhancement. The current Debian
> | policy for systemd needs to be finished and agreed, and then
> | incorporated in the policy manual. We encourage the maintainers of
> | upstart and systemd, and others, to submit relevant policy
> | enhancements.
> |
> | Contributors should delay introducing patches for native support
> | for upstart, systemd or openrc until the relevant Debian Policy is
> | declared, by the Policy editors, to be ready. ]
> |
> | Support requirements for packages:
> |
> | 5. Subject to paragraphs 4 and 6 of this resolution, packages should
> | provide native upstart jobs where relevant.
> |
> | Lack of native upstart support is not a release-critical bug for
> | jessie.
> |
> | [ Patches for upstart support should be treated the way "release
> | goals" have been treated in the past; so, for example, there should
> | be a low NMU threshold for patches meeting suitable criteria.
> |
> | The Debian Project Leader and/or applicable Delegates should give
> | effect to this part of our decision. ]
> |
> | 6. [ Maintainers should accept reasonable patches for native upstart,
> | systemd and openrc support.
> |
> | A. A reasonable patch:
> | (i) is proposed after the relevant policy is finalised;
> | (ii) complies with that policy;
> | (iii) complies with the advice and requirements in this
> | resolution; and
> | (iv) takes the approaches to integration chosen by upstream,
> | or failing that by the Debian maintainer.
> |
> | B. A patch is not unreasonable just because:
> | (i) the package upstream (or the Debian maintainer) does not wish
> | to support the relevant init system at all; or
> | (ii) they do not wish to support any of the suitable non-forking
> | startup protocols offered by that init system.
> |
> | C. However, a maintainer is entitled to consider a patch unreasonable
> | if it:
> | (i) Requires additional build-dependencies; or
> | (ii) Requires additional runtime dependencies except sysv-rc; or
> | (iii) Introduces other than trivial new code into the daemon; or
> | (iv) "Abuses" SIGSTOP as done by the upstart "expect stop"
> | protocol and as disliked by the systemd community.
> |
> | Code to write to an already-open fd and close it, or to raise a
> | signal, will usually be trivial for these purposes. (This includes
> | enabling the new protocol via command-line switches or environment
> | variable tests, and removing any small fixed set of associated
> | variables from the environment.) Code to connect to an AF_UNIX
> | socket and send a message will not usually be considered trivial.
> |
> | We are aware that at present it is not possible to provide a patch
> | for any of systemd's or upstart's main non-forking daemon startup
> | readiness protocols which is necessarily reasonable by this
> | definition.
> |
> | Therefore if the upstart and systemd communities in Debian want the
> | widest adoption in the project, these problems should be addressed
> | by changes to the upstart and systemd package to widen their
> | support for different startup protocols. Ideally each init should
> | in any case provide support for the main protocols supported by
> | their competition.
> |
> | Failure to apply reasonable patches, including failure to explain
> | promptly and constructively why a patch is not reasonable, is
> | likely to lead to the maintainer being overruled. ]
> |
> | Detailed policy specifications:
> |
> | 7. [ No package in Debian should use "expect fork" or "expect daemon"
> | in upstart jobs. The corresponding code in upstart may be disabled
> | or compiled out on some or all architectures. ]
> |
> | 8. Policy rules for support for init systems must:
> |
> | (a) Specify the use of a non-forking startup protocol (for
> | upstart and systemd),
> |
> | (b) Use facilities documented in the reference manuals for the init
> | system in question (as found in sid). [ This requirement
> | cannot be met until the init system has a suitable reference
> | manual. ]
> |
> | (c) Require that environment variables and fds involved in the
> | daemon startup protocol should not in general be inherited by
> | the daemon's descendants.
> |
> | (d) Forbid the introduction of embedded copies of library code
> | (or the use of any embedded copies included by upstream).
> |
>
| 9. [ Policy should provide non-binding suggestions to Debian
> | contributors who are converting daemons to upstart and/or systemd,
> | for example:
> |
> | (a) If changes are necessary to the core daemon code, make those
> | changes acceptable to the daemon's upstream if possible.
> |
> | (b) It is fine to introduce new code in the main body of the daemon
> | to support non-forking startup, socket activation or readiness
> | signalling.
> |
> | (c) Support for upstart is usually best provided with the
> | raise(SIGSTOP) non-forking daemon readiness protocol, unless
> | and until a better protocol is available.
> |
>
Should it not be added that raise(SIGSTOP) should only be used with a
command line option (like --debian-Z) to ensure that the daemon does not
hang on sysv or systemd?
Cheers,
Cameron Norman
