Tackling service management with Linux systemd

Systemd is a radical change from the old method of Linux service management. It provides a generic interface not just for services, but also for hardware management.

Until the launch of Linux Upstart a few years ago, Linux used an init-based startup procedure. Upstart was designed to make Linux startup more efficient, but it had a very short life. It was barely off the drawing board when systemd came along and replaced it on major Linux distributions as the method for service startup and management.

IT admins accustomed to finding service scripts in the /etc/[rc.d/]init.d directory of their favorite Linux distribution will notice they aren’t there anymore. All that remains are a limited number of services that don’t have a systemd startup script yet. On a Fedora system, the systemd services are in the /etc/system/system directory that contain symbolic links to the real location of the service scripts in usr/lib/system/system. In this directory, a subdirectory named multi-user.target.wants contains service scripts for the services that a system has installed.

In Linux systemd, the concept of runlevels was dropped. While booting, the computer goes through a series of phases, which are referred to as wants. The definition of a want is not as strict as the definition of a runlevel, so you will see differences here between the different Linux distributions. On a Fedora 17 system, for instance, you’ll find the following important wants:

• sysinit.target.wants: contains scripts that have to be started at a very early stage
• basic.target.wants: more scripts that have to be started at a very early stage
• multi-user.target.wants: normal services that you typically need to have an operational system

In addition to these generic wants, there are some specific ones. You may find, for instance, the bluetooth.target.wants (to start Bluetooth) and the getty.target.wants used to initialize the ttys for users. In these wants you’ll find the service scripts themselves. But again, you’ll notice there are differences between the distributions, as every distribution can create its required wants.

The startup scripts themselves aren’t really startup scripts anymore. In the old startup procedure, bash shell scripts were used to launch services. Now you’ll find startup scripts that pass parameters required by systemd to start the services, which makes it very easy to understand how a service is started (see Example 1).

Example 1: A system-style init script for Linux systemd.

[root@IAD multi-user.target.wants]# cat sshd.service
[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

This very clean service script defines variables that systemd uses. All of the service scripts follow more or less the same syntax, which makes managing them a lot easier compared to the diverse init scripts.

Not only does systemd take care of items that were considered services in an init-based startup, it also handles part of hardware management. So when looking into the services system manages, administrators will see network devices, ttys and more.

Using systemctl to manage Linux services

The systemctl command, used for managing services, replaces old commands likeservice and chkconfig, which you’ll only have to use to manage old services that don’t have a systemd-compatible script. Start by typing systemctl by itself. This shows a list of all services Linux systemd manages as well as their current statuses (see Example 2).

Example 2: Use systemctl to show a list of services 

mdmonito…keover.service	loaded active exited	Software RAID Monitor Takeover
mysqld.service	loaded active running	MySQL database server
NetworkManager.service	loaded active running	Network Manager
nfs-idmap.service	loaded active running	NFSv4 ID-name mapping daemon
nfs-lock.service	loaded active running	NFS file locking service.
nfs-mountd.service	loaded active running	NFS Mount Daemon
nfs-rquotad.service	loaded active running	NFS Remote Quota Server
nfs-server.service	loaded active exited	NFS Server
ovirt-engine.service	loaded active running	oVirt Engine
postgresql.service	loaded active running	PostgreSQL database server
prefdm.service	loaded active running	Display Manager
rpcbind.service	loaded active running	RPC bind service
rsyslog.service	loaded active running	System Logging Service
rtkit-daemon.service	loaded active running	RealtimeKit Scheduling Policy Service
sendmail.service	loaded active running	Sendmail Mail Transport Agent
sm-client.service	loaded active running	Sendmail Mail Transport Client
smartd.service	loaded active running	Self Monitoring and Reporting Technology (SMART) Daemon
spice-vdagentd.service	loaded active exited	LSB: Agent daemon for Spice guests
sshd.service	loaded active running	OpenSSH server daemon
system-s…yboard.service	loaded active running	System Setup Keyboard
systemd-journald.service	loaded active running	Journal Service
systemd-logind.service	loaded active running	Login Service
systemd-…ollect.service	loaded active exited	Collect Read-Ahead Data

For status information about a specific service, use systemctl show followed by the name of the service. The service name typically includes the suffix .service, so use systemctl status sshd.service and not systemctl show sshd.

Systemctl has other useful display options as well, such as systemctl show servicename.service, which lists the current configuration of a particular service.

Example 3: Use systemctl status servicename.service to see the current status of a service

[root@IAD ~]# systemctl status sshd.service

sshd.service – OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Wed, 06 Mar 2013 07:44:53 +0100; 6h ago
Process: 1043 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 1085 (sshd)
CGroup: name=systemd:/system/sshd.service
â 1085 /usr/sbin/sshd -D

Mar 06 13:42:32 IAD.example.com sshd[4590]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:43:32 IAD.example.com sshd[4602]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:44:32 IAD.example.com sshd[4610]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:45:32 IAD.example.com sshd[4618]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:46:32 IAD.example.com sshd[4630]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:47:32 IAD.example.com sshd[4639]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:48:32 IAD.example.com sshd[4651]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:49:32 IAD.example.com sshd[4660]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:50:32 IAD.example.com sshd[4670]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:51:32 IAD.example.com sshd[4686]: Connection closed by 127.0.0.1 [preauth]

To start a service for the first time, use systemctl start servicename.service; to stop that service, use systemctl stop servicename.service. These allow you to start or stop a service once. If you want a service to start every time your computer boots, usesystemctl enable servicename.service. If you don’t want the service on your computer at all, use systemctl disable servicename.service.

Original page is here