Bug#727708: Thoughts/Summary on the init-system
Hi together,
first of all, sorry for being so late to this party.
I'll start with describing a few facts, observations and thoughts, and come
to my conclusions at the end of this mail. I don't write references at
places where I believe had already sufficient coverage by others and/or are
more or less not really doubted. I also didn't write at all possible
required locations "as far as reasonable" or similar - I assume and expect
that we all try to integrate our system as good as reasonably possible
without wasting too much time for details nobody cares about, and I didn't
want to write it at all places again and again. (And just because something
is technically possible doesn't mean it is reasonable possible, and if I
write "possible" below it refers to "reasonable possible", and same with
similar words.) Also I try to not repeat too much of what had already been
written by others, especially in other summaries.
What are we speaking about? There are three different things: The
pid1-provider, means: what is init in the terms of the linux command line
(current default: sysvinit). Then the runlevel-manager (current default:
sysv-rc). And then a daemon which could start and stop other services
(which is always provided by the pid1-provider, but there are other in
Debian, and as long as they could be used at the same time together, I
don't think there is any conflict, and so no reason for a decision).
Also, as discussion has shown, we speak about what is default in Debian
(please note that this could be more than one overall, so it might be
"defaults in Debian"). Then, what is required to be supported (at least
what is default anywhere on a architecture in testing). And then what else
are maintainers supposed to support on an higher than wishlist level.
State of the different init systems: First of all, I think that all three
contenders are better than our current state. Systemd and upstart are way
better, openrc still is a major improvement about sysv-rc. So all three are
in the game for me.
I however don't believe that we could realistically support all three
(four) equally good at the same time. It might had worked if somebody would
have found a clever meta-format that could be autoconverted by debhelper in
almost all cases, but as none is there yet I doubt it's realistic. It might
work that we support two of them at the same time, but even that is a bit
painful for us (and there should probably be some autotesting then as
suggested by Anthony recently).
So, what could realistically work:
On the linux ports, all would work. On the kbsd ports I believe that both
upstart and openrc could be working, but none is yet. For hurd, at least
openrc could and probably also upstart.
Porting systemd to kbsd or hurd is not realistic from what I understood
(unless they basically clone the linux cgroups feature), but a parallel
implementation of programm with similar configuration files would be
possible (but I don't believe in that, especially for the long-term
maintenance[1]). Porting upstart seems to be possible, but has the CLA-issue
which makes flowing patches back to upstream harder (and therefor I would
recommend Canonical to not use this policy for upstart), so we would have
to carry extra patches within Debian (which however doesn't look as painful
as a parallel implementation of systemd). Openrc looks like it could work
"in the upstream way" everywhere, but needs a bit of porting.
I don't believe that it would work long-term if we use systemd on Linux and
upstart on !Linux.
[1] Having a parallel implementation of systemd for kbsd would mean that we
also need to take care that e.g. logind is useable without systemd. Which
however means that we'll have the same work required to use non-systemd as
default on Linux plus some additional work for the systemd-mimikri. Doesn't
sound too attractive to me.
All of that together boils down to these options for the default
pid1-provider / runlevel manager (perhaps after some more porting in this
cycle):
1. Systemd on Linux, openrc/sysv-rc on non-Linux
2. Upstart everywhere
(3. openrc/sysv-rc everywhere - as both systemd and upstart are better, I don't
think this ends high enough on my priority list; see below for details)
What does "required to be supported" mean? Basically the same as always -
the basic functionality needs to be good useable, and everything else
reasonable supportable as well. And any "required to be supported" provider
needs to be supported at least to the same amount as any other. This
doesn't mean that functionality needs to re-invented just because it is
technically possible. To take an example from a recent irc conversation, I
don't think it's sensible to expect people to do multi-instance setup in
sysv-rc just because it is technically possible (but extremly painful) and
it is done in (systemd or upstart), but on the other hand, if systemd would
be the default and sysv-rc not anymore and someone does multi-instance in
sysv-rc I would expect it to be done in systemd as well.
Also the question did arise what programs are allowed to depend upon? Could
some program say it needs one specific pid1-provider or runlevel-manager?
For the question of "could Y be required as a supervising daemon" (like
cereal depends on runit) I think we all agree it is possible, as long as Y
doesn't require to be alone on the system (i.e. it doesn't require to be
able to exclusivly control ressources); this even isn't for me for the tech
ctte to decide because I don't think someone asked us that question. For
the runlevel-manager and pid1-provider, I don't think that programs should
be allowed to require one exclusivly - of course, some advanced
functionality might be restricted to some managers/providers, but the
program should not be unnecessary limited and willing to integrate other
runlevel-manager/pid1-provider to the same amount if they provide same
functionality.
Support of more than one pid1/runlevel-manager?
This is one of the core questions. If we end up with an init system which
only works on Linux, we need to support at least two (however perhaps on
Linux only one and another one only on non-Linux).
Expecting that we could support all three realistically well is an
expectation I am not sharing. However, I think we could have the
expectation that our users should be able to exchanges those providers
without the system totally falling to pieces or deinstalling core
components of the system (like people could today - e.g. runinit could be
used to name one not on the hotlist of many minds). I also think we should
have the expectation that exchanging of initsystems should continue to be a
possiblity (this is more a mindset-question - because of course as today it
might mean that people would have to invest time into that, but I could
consider many reasons for a debian derivative to use e.g. openRC as
provider; as said I don't expect to be easily possible but we should still
be welcoming people trying other init systems, and be happy about accepting
patches when they're ready).
So we could converge on one pid1/runlevel-manager only if we choose one
which is (going to be) available on all platforms.
Support of !linux platforms
>From a long-term perspektive our non-linux-platforms as well as the
non-x86-linux platforms have done us very good in getting our code in good
shape, and help even on the mainstream linux platforms to find bugs earlier
/ better (e.g. hurd with removal of static buffers). For details see e.g.
87txd35snd.fsf@windlord.stanford.edu">http://lists.debian.org/87txd35snd.fsf@windlord.stanford.edu
For this reason, I consider it important to make sure our
non-linux-platforms are reasonable well supported.
Vendor lockin
This is a question which is relevant for both Upstart and Systemd. Answers
are different, but I'm not happy with either Upstart being so
canonical-centric (yet?) and systemd pulling more and more parts of the
base system into it. The later gives me even more concerns, because it
means that our current flexibility in some of these parts will be steadily
going down in the long run (see e.g. the relation between kbd and systemd
in Collins mail for what that means - we are trading parts of our quality
for more systemd integration, and I'm not sure that this is always a good
trade). In fact, systemd would look better to me if it would be less
invasive.
Implementation details
For openrc, this is a moving target. When I looked at it first during the
start of this discussion, it was not even in experimental (and still is not
in unstable), and documentation was hard to get. This has improved but
still it is worse then the others. Also having a no-double-fork-setup for
demons is something really useable, and I haven't seen any answer on that
during time of writing this. I appreciate the work that had been put into
openRC, and I believe openRC is a major improvement over sysv-rc, and will
also continue to have a useful place in the linux/unix ecosystem. I
recommend openRC developers to keep up their good work. However for Debian
I think it will not be our default choice for the Linux-architectures.
Sorry.
For systemd / upstart I also refer here mostly to other mails, e.g.
20140118044132.GD12912@teltox.donarmstrong.com">http://lists.debian.org/20140118044132.GD12912@teltox.donarmstrong.com
Systemd and upstart both have made different decisions implementation wise,
but in the end the core topics (e.g. service startup notification,
dependencies vs events, format of configuration files, documentation) are
reasonable well resolved, so that I don't think that makes a relevant
difference for the decision. (For the service startup notification I
would recommend both to support the other protocoll as well, but
nothing which should be part of a resolution.)
Logind support for !systemd-based systems
Logind seems to become an vital part for any desktop service. I seriously
hope it will be continued to be maintained in a way that doesn't require
systemd (independend of how debian decides for the pid1-provider), even
though since release 205 this is harder or needs to be forked. See e.g.
52DBE12B.7040603@debian.org">http://lists.debian.org/52DBE12B.7040603@debian.org for details. I don't
see how this would be part of a decision right now, but is an important
detail. (Some more details about cgroups, linux-centrisms, problems of that
etc are in
CAJS_LCXTpS1xdY6OWf6eQWZ5JWUJcCJ0sio8KaDakqwv2k8S+g@mail.gmail.com">http://lists.debian.org/CAJS_LCXTpS1xdY6OWf6eQWZ5JWUJcCJ0sio8KaDakqwv2k8S+g@mail.gmail.com
- and thanks Anthony for your good mails in the current discussion).
Now, putting that all together, from the options above "systemd for Linux,
openrc/sysv-rc for !linux" or "upstart everywhere" I prefer the upstart
choice. Reasons for this see many details above, supporting all the
required features, not as invasive in the debian system, saving us to
integrate more than one init system reasonably well etc.
Andi
Reply to: