Bug#727708: init system thoughts
Hi,
first, thank you for describing this problem in details.
I have never met it while using systemd on Debian Wheezy and sid for
18 months. Anyhow, with your indications at hand, I realize that my
use cases probably fall into the category that does not expose
this problem.
Steve Langasek wrote (03 Jan 2014 01:19:40 GMT) :
> Without an equivalent to failsafe.conf, server systems converted from
> sysvinit to systemd will find some of their (poorly-coded, but nevertheless
> common and supported in Debian) services randomly failing to start on boot
> where they started reliably before.
Just to check that I understood you correctly: this will be the case
"only" for services that do not provide systemd integration, right?
I'm obviously not saying we should disregard these, but I think it is
useful for this discussion to clearly state which packages would be
affected, and which would not.
> The kinds of race conditions that I'm highlighting here are ones
> that Ubuntu identified and resolved over the course of two years of
> experience with Upstart in the wild, at the cost of quite a bit of
> pain for Ubuntu's users in the meantime.
Trying to better evaluate the required effort, I am wondering to what
extend Debian would benefit from the "Ubuntu identified" part, even if
the fixes cannot be directly translated to systemd. So, I have a few
questions for you.
First, do you expect the list of race conditions identified and
resolved in Ubuntu to cover most of those that could hit Debian if we
were to use systemd?
Second, if we don't want to simply wait for the bugs to roll in, as
you put it, regardless of whether we go with systemd or upstart, we
will need to build this list at some point (to measure progress, to
start with the most critical issues, and in last resort to document
remaining ones in the release notes). The earlier, the better.
I wonder how spread out the information is. Does the resolution of
these problems live primarily in upstart jobs (easily gathered), or in
other kinds of Ubuntu-specific patches (flagged in a special way to
make upstreaming easier, I would hope), or elsewhere? If the answer is
"meld in various kinds of Ubuntu-specific patches", how do we identify
the relevant bits?
It seems to me that the answer to this last set of questions is not
only relevant in case we pick systemd, but also if we choose upstart:
if *gathering* this list of problems and (upstart-specific) solutions
is hard for Debian+systemd, then I fail to see why it would be easy
for Debian+upstart.
If we agree that compiling this list will be needed at some point
anyway, I'm now wondering if it would perhaps be useful input for the
current decision making process: not only it would help us assert the
scope of the problem, but it would avoid a potential outcome I am
personally scared about: after picking upstart in part because
integrating it would be so much easier, realizing later that, oh well,
the best we can do is often to go dig stuff from
https://patches.ubuntu.com/ as we see bug reports roll in.
> [...] no other distribution that has adopted systemd has dealt with
> these issues yet.
If I were among the ones who make the decision, I would want to see
this statement supported by a list of bugs caused by this fact, that
were reported against distributions that ship systemd by default.
Anyway, I'm curious, but if I'm the only one who cares, please don't
waste your time on it :)
Also, I suppose that Red Hat is actively tackling these issues, with
RHEL7 now in beta. It is not clear to me what amount of their fixes we
can (find and) take if we pick systemd. Same here, depends how broadly
the fixes are gathered, and how deeply they are meld in with changes
we do not care about, I guess.
> If we decide for systemd, what do you think is the right way to
> mitigate such problems for jessie? Some of these issues are only going to
> be seen once people start making use of systemd in anger with their existing
> server configs (e.g., an ec2 VM with a simple disk and network config is not
> going to expose these problems), and I don't really think we want to do this
> by way of switching the default in unstable and waiting for the bugs to roll
> in.
I think that designing a good plan depends quite a bit on the answer
to questions above, wrt. reusing the list of race conditions
identified by Ubuntu, and the corresponding list of fixes.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
Reply to: