systemd, a brave new world

4 September 2014 21:50

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:

#!/bin/sh
#
# 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.

Tags: docker, systemd, wheezy | 5 comments

Comments on this entry

Philipp Kern at 02:05 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).

Cameron Norman at 02:56 on 4 September 2014

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

Derek at 03:12 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.

Sjoerd at 06:47 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 (http://www.freedesktop.org/wiki/Software/systemd/Generators/).

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.

Ganto at 12:04 on 4 September 2014
http://linuxmonk.ch

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.

[1]: https://github.com/ibuildthecloud/systemd-docker

Cheers, ganto

systemd, a brave new world

Comments on this entry

Recent Posts