Bug#727708: upstart ./. ptrace, sockets, etc.
On Fri, 01 Nov 2013 09:30:22 -0700
Russ Allbery <rra@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
Reply to: