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 1000How 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.serviceThese will spit out a whole lot of output, probably a hundred lines or more. Want to see only active services?
$ systemctl list-units -t serviceYou 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.serviceOr use
restart to restart a running service. This stops a service:# systemctl stop sshd.serviceThose are in effect only for the current session, so if you want a service to start at boot do this:
# systemctl enable sshd.serviceAnd that's all. No hassling with startup scripts. This disables it from starting at boot:
# systemctl disable sshd.serviceYou 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 0You 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 theps 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.
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.serviceLennart 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
- Rethinking PID 1
- systemd for Administrators, Part 1
- systemd for Administrators, Part II
- systemd for Administrators, Part III
- systemd for Administrators, Part IV
- systemd for Administrators, Part V
- systemd for Administrators, Part VI
- systemd for Administrators, Part VII
- systemd for Administrators, Part VIII
- systemd for Administrators, Part IX
- systemd for Administrators, Part X
- systemd for Administrators, Part XI
No comments:
Post a Comment