On Fri, 01 Nov 2013 09:30:22 -0700 Russ Allbery <r...@debian.org> wrote:
> I don't personally consider this a major issue It's probably not something that cannot be worked around in some way, as the upstart position statement asserts (which by the way I *have* read). However, IMHO systemd's cgroups solution makes a whole lot more sense from a technical PoV, and also fixes a couple of other problems which SysV init is notorious for. Apropos of upstart's position statement, it says that > upstart provides more granular definitions of service readiness > that are not available in systemd. Personally I consider this to be a bug. A daemon either can accept requests, or it cannot. A file system is either mounted, or it is not. Anything else is internal fiddling by the init subsystem and should not be of any interest, or in fact visible (unless you're debugging daemon startup), to anybody else. … and another thing, speaking about accepting requests: One of the interesting side effects of socket activation, as implemented by systemd, is that one can restart a service (even one using multiple sockets and dbus and whatnot) without losing a single request. AFAIK, upstart cannot do that: its socket activation only passes a single socket to the daemon, if I interpret the manpage at http://manpages.ubuntu.com/manpages/raring/en/man7/socket-event.7.html correctly. This is an example of the fundamental difference between upstart's model, which is based on events, and systemd's, which relies on service states and dependencies. IMHO the systemd model makes a lot more sense, from the PoV of a system administrator. You can easily ask systemd which preconditioon prevents a daemon from starting up. Asking upstart which event ultimately failed to fire for (one of?) a daemon's "start on" conditions to be fulfilled is a more "interestig" problem. ***** My personal bottom line is that systemd has a whole lot of features which I am already taking for granted -- I started using systemd as my primary init system on a wide range of Debian systems since it showed up in Experimental -- and which other init implementations do not provide. To be perfectly frank, I'd rather switch distros than stop using systemd. IMHO, maintaining "duplicate" init scripts for <whatever we decide non-Linux Debian systems should standardize on> would consume far less manpower than re-implementing systemd's journal, and re-implementing a cgroups controller, and getting whatever we decide on to work with kdbus in the future, and getting logind and whatnot to run without systemd, and getting gnome (and maybe others) to not require systemd as PID 1, … the list goes on. To be fair, some of this work is going to be necessary anyway, assuming that Debian continues to treat non-Linux kernels as first-class citizens. However, the burden of doing it (and to live with the inevitable bugs) should be carried by those who require it. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
