Bug#727708: loose ends for init system decision
We have been asked to decide the default init system for jessie. As I
have just said, my conclusion is that we should choose upstart.
However, we also need to decide whether we intend to allow users to
choose otherwise. So we need to say what we expect of package
maintainers in terms of support for other init system(s).
It seems to me that the benefits of upstart integration are such that
we should encourage transition to upstart jobs, subject to my concerns
about the need for a new readiness protocol.
I am not comfortable with the idea of /mandating/ use of upstart. We
may discover that despite our adoption, upstart loses the war, or we
may find that we want to switch to openrc or another contender. And,
given the strong opinions on this topic, I think it is at the very
least premature to tell our users and downstreams that they are on
their own if they want to use systemd.
At the moment, there is no meaningful compatibility layer between all
these systems other than sysvinit scripts. This is unfortunate, but
given the current state of development of both systems I think this is
to be expected.
So I'm sorry to say that I think we need to continue to maintain
sysvinit scripts in jessie. The alternative would be to permit a
package to drop sysvinit support if both systemd and upstart
configuration were provided, but I'm not happy at this stage to burn
our bridges like that.
It would be worth researching some kind of compatibility options.
Perhaps simple daemons with very formulaic upstart job files could
have synthetic systemd units created. Or something.
I think we should give package maintainers some guidance on what kinds
of upstart or systemd patches should be accepted. Without this, it's
likely we'll find ourselves adjudicating disputes that ought to have
been settled in principle much earlier.
I think that patches for either should:
- use a non-forking startup method
- avoid significant amounts of open-coded AF_UNIX socketry
- avoid embedded copies of daemon library code
- avoid extra build-dependencies (eg on libsystemd)
- avoid extra runtime dependencies (eg on deb-systemd-helper)
(If the current state of the art in readiness protocols persists that
means that upstart patches using raise(SIGSTOP) ought to be accepted,
but systemd ones rejected unless they can use socket activation.)
We should recommend:
- daemon authors and Debian maintainers should prefer command-line
options to environment variables
- whatever environment variables and fds are used, measures should be
taken to avoid them being inherited by daemons' arbitrary children
IMO we should treat native non-forking upstart support as we have in
the past done for release goals, ie with a low threshold NMU policy of
some kind.
But as I say I would like to see us try to get agreement or
near-agreement on an improved startup protocol. I would suggest that
we allow (say) a month for this process, starting now. Before this is
settled we shouldn't go around converting a whole bunch of daemons.
And, there are two loose ends about systemd in particular:
- There doesn't seem to be any Debian policy about how to
provide systemd units in Debian;
- systemd upstream and the Debian maintainers like to put much of the
configuration in /lib; this is controversial and someone needs to
decide whether this is appropriate.
Ian.
Reply to: