systemd, a brave new world

Thursday, 4 September 2014

After spending a while fighting with upstart, at work, I decided that systemd couldn't be any worse and yesterday morning upgraded one of my servers to run it.

I have two classes of servers:

  • Those that run standard daemons, with nothing special.
  • Those that run different services under runit
    • For example docker guests, node.js applications, and similar.

I thought it would be a fair test to upgrade one of each systems, to see how it worked.

The Debian wiki has instructions for installing Systemd, and both systems came up just fine.

Although I realize I should replace my current runit jobs with systemd units I didn't want to do that. So I wrote a systemd .service file to launch runit against /etc/service, as expected, and that was fine.

Docker was a special case. I wrote a docker.service + docker.socket file to launch the deamon, but when I wrote a graphite.service file to start a docker instance it kept on restarting, or failing to stop.

In short I couldn't use systemd to manage running a docker guest, but that was probably user-error. For the moment the docker-host has a shell script in root's home directory to launch the guest:

# Run Graphite in a detached state.
/usr/bin/docker run -d -t -i -p 8080:80 -p 2003:2003 skxskx/graphite

Without getting into politics (ha), systemd installation seemed simple, resulted in a faster boot, and didn't cause me horrific problems. Yet.

ObRandom: Not sure how systemd is controlling prosody, for example. If I run the status command I can see it is using the legacy system:

root@chat ~ # systemctl status prosody.service 
prosody.service - LSB: Prosody XMPP Server
      Loaded: loaded (/etc/init.d/prosody)
      Active: active (running) since Wed, 03 Sep 2014 07:59:44 +0100; 18h ago
      CGroup: name=systemd:/system/prosody.service
          └ 942 lua5.1 /usr/bin/prosody

I've installed systemd and systemd-sysv, so I thought /etc/init.d was obsolete. I guess it is making pretend-services for things it doesn't know about (because obviously not all packages contain /lib/systemd/system entries), but I'm unsure how that works.



Comments On This Entry

[gravitar] Philipp Kern

Submitted at 02:05:40 on 4 september 2014

sysvinit compatibility is one of the awesome features. It will create a service stub for all init scripts unless there's a identically named systemd service file for them. So you can depend on init scripts from systemd services (and vice versa, through LSB headers).

[gravitar] Cameron Norman

Submitted at 02:56:54 on 4 september 2014

systemd can run init scripts by reading the LSB headers and then just running /etc/init.d/prosody start / stop.

[gravitar] Derek

Submitted at 03:12:06 on 4 september 2014

The discussion you have at the end is the LSB compatibility that systemd has. If it finds an "X".service file, it masks the /etc/init.d/"X" script. Otherwise, it uses the LSB information in the file to fit it in to the dependencies graph.

I think, anyway.

[gravitar] Sjoerd

Submitted at 06:47:11 on 4 september 2014

LSB service (thus /etc/init.d and friends) are obsolete but still supported.. In older systemd versions this was supported directly in systemd itself, for newer versions (>= 214) a generator generates the services on the fly (

In all cases native services have priority, so if you were to write your own prosody.service that would be used instead of a service which just runs the init script.

[gravitar] Ganto

Submitted at 12:04:41 on 4 september 2014


I'm using systemd-docker [1] for running docker containers as native systemd services. So you can manage docker containers via systemd (start/stop/status) or via docker commands.
If you manage docker containers via service files don't forget to disable autostart within docker, otherwise the daemon will already start the previously running containers.


Cheers, ganto


Comments are closed on posts which are more than ten days old.

Recent Posts

Recent Tags