Sunday, December 25, 2011

Managing Services on Linux with systemd


  You've read all about systemd, the new Linux init daemon. You know what it does, and why. Now it's time to dig in and learn how to make it sit up and beg — or at least start, stop, and get information on services.

Starting and Stopping Services

My earlier piece, "Here We Go Again, Another Linux Init: Intro to systemd" discusses the concepts behind systemd and what it is supposed to do. Now it's time to learn how to use it to control services on our systems. systemd is backwards-compatible with sysvinit and Upstart, so you can try it out by installing it on any Linux that uses sysvinit or Upstart without a lot of extra work. Arch Linux, Debian, and OpenSUSE all include systemd in their software repositories.
A conspicuous omission from distros that support systemd is Ubuntu. There are various reasons given for this, and I don't care because I'm tired of geekfights and just want to get on with things. Another way is to fetch yourself a copy of Fedora 15 or 16, which runs systemd by default.


systemadm is a nice graphical systemd manager (figure 1). It's still a baby so it might crash or something, but you can try it by installing the systemd-gtk package on Fedora, the systemd package on Arch, or the systemd-gui for Debian. No, of course distros cannot use consistent package naming, because that is against the rules.
As pretty as systemadm is, let us adjourn to the command line for the rest of this article. Watch the prompts in the examples to see which ones require root privileges. You can see the status of everything systemd controls by running systemctl with no options:
$ systemctl
UNIT                                              LOAD   ACTIVE SUB       JOB DESCRIPTION
proc-sys-fs-binfmt_misc.automount                 loaded active waiting       Arbitrary Executable File Formats File System Aut
sys-devices-pci0...000:00:1b.0-sound-card0.device loaded active plugged       82801I (ICH9 Family) HD Audio Controller
sys-devices-pci0...-0000:05:00.0-net-wlan0.device loaded active plugged       Centrino Wireless-N 1000
How do you see only available services, running or not?
$ systemctl list-units -t service --all
UNIT              LOAD   ACTIVE   SUB   JOB   DESCRIPTION
ceph.service      loaded inactive dead        LSB: Start Ceph distributed filesystem daemons at boot time
chronyd.service   loaded active   running     NTP client/server
cman.service      error  inactive dead        cman.service
These will spit out a whole lot of output, probably a hundred lines or more. Want to see only active services?
$ systemctl list-units -t service
You can check the status of any individual service, such as the cman.service, which has an error flag in the previous example:
$ systemctl status cman.service
cman.service
   Loaded: error (Reason: No such file or directory)
   Active: inactive (dead)

How nice, it tells us what the problem is. Here is what a normal running service looks like, with complete information on the service:
$ systemctl status sshd.service
sshd.service - OpenSSH server daemon
   Loaded: loaded (/lib/systemd/system/sshd.service; enabled)
   Active: active (running) since Thu, 15 Dec 2011 12:11:05 -0800; 2h 26min ago
 Main PID: 2091 (sshd)
   CGroup: name=systemd:/system/sshd.service
      \   2091 /usr/sbin/sshd -D

On Fedora you can still use the old service and chkconfig commands. But why not start learning the new systemd commands? This is how to start a service:
# systemctl start sshd.service
Or use restart to restart a running service. This stops a service:
# systemctl stop sshd.service
Those are in effect only for the current session, so if you want a service to start at boot do this:
# systemctl enable sshd.service
And that's all. No hassling with startup scripts. This disables it from starting at boot:
# systemctl disable sshd.service
You can check to see if a service is already running; 0 means it is currently running and 1 means it is not:
$ systemctl is-enabled sshd.service; echo $? 
enabled
0
You can use systemctl halt, poweroff, or reboot to shutdown or reboot the system. All three send a wall message to users warning that the system is going down.

Processes, cgroups, and Killing

systemd organizes processes with cgroups, and you can see this with the ps command, which has been updated to show cgroups. Run this command to see which service owns which processes:
$ ps xawf -eo pid,user,cgroup,args 
  PID USER     CGROUP                      COMMAND
 1338 root     name=systemd:/user/carla/2       \_ gdm-session-worker [pam/gdm-password]
 1358 carla    name=systemd:/user/carla/2           \_ /bin/sh /etc/xdg/xfce4/xinitrc
 1487 carla    name=systemd:/user/carla/2               \_ /usr/bin/ssh-agent /bin/sh -c exec -l /bin/bash -c "startxfce4"
 1515 carla    name=systemd:/user/carla/2               \_ xscreensaver -no-splash
 1517 carla    name=systemd:/user/carla/2               \_ xfce4-session

cgroups were introduced into the Linux kernel a few years ago, and they are an interesting mechanism for allocating and limiting kernel resources. In systemd, cgroups are used to corral and manage processes. When new processes are spawned they become members of the parent's cgroup. The cgroup is named for the service it belongs to, and services cannot escape from their cgroups so you always know what service they belong to. When you need to kill a service you can kill the cgroup, and snag all of its processes in one swoop instead of playing find-the-fork-or-renamed-process. Another way to view the process hierarchy is with the system-cgls command, as shown in Figure 2.

Figure 2: Partial output from system-cgls showing process cgroups.
Figure 2: Partial output from system-cgls showing process cgroups.

There is my old friend Avahi daemon. So instead of hunting down and killing the two Avahi processes the old-fashioned way, systemd lets me do it in one command:
# systemctl kill avahi-daemon.service
Lennart Poettering, the main author of systemd, has written a series of articles for sysadmins. They're not indexed, so here are links for your convenience. These cover customizing startup services, runlevels, gettys, and everything you need to know to control systemd




No comments:

Post a Comment