[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: Quick upstart and systemd feature comparison



I took a fairly quick look at the features provided by upstart and systemd
for starting and managing daemons, since that's the part that I feel the
most qualified to evaluate.  I've been trying out different methods for
doing that for about 15 years and run a bunch of production systems with a
variety of different daemons, so I have strong opinions about what
features I want.

The short version is that both upstart and systemd directly support most
of the things that are annoying or repetitive to handle with init scripts.
Both of them strike me as sufficient.  systemd has some specific features
that upstart appears not to have that I would immediately use in my day
job if I had them available.

I had difficulty finding equivalent documentation for OpenRC so that I
could check its feature list against the things I've needed, but I see
that Ian already asked about that, so I will read whatever documentation
he's pointed to.

Features both upstart and systemd have over sysvinit that I would
immediately start using at work:

* Process monitoring and automatic restarting
* Setting process user and group
* Setting process priority
* Linux OOM killer score adjustment
* Process limits (I would use file descriptors, primarily)
* Multiple instances of a given service

The last feature is extremely nice and would replace a lot of nasty and
difficult-to-maintain code both at my day job (to run multiple copies of
Apache, for example) and in Debian (consider the Tomcat init script).  I
think the upstart implementation of this is cleaner and easier to
understand, and the systemd implementation is kind of weird, but it looks
like the functionality is equivalent.

Features that systemd provides that I didn't see in upstart (please
correct me if I'm wrong):

* StandardError=syslog.  This would be *so nice* for *so many things*.
  Particularly for running Java applications, which are very bad about not
  sending everything to syslog even when one tries to write them to do so.
  I would start using this immediately.  There are various external
  programs that can do this, but with sysvinit you have to set up the
  pipelines yourself and worry about the programs dying, whereas systemd
  takes care of all of that.

* Lots of really interesting defense-in-depth security features.  I
  particularly liked ReadWriteDirectories, ReadOnlyDirectories,
  InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which
  provide a sort of lightweight process containment that would be much
  easier to use than a full-blown chroot, and in some ways more powerful.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: