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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
