Subcommands for managing services are the same as for managing a service with SysV init (start, stop, ...). The general syntax for service management commands is as follows:

systemd allows to manage several services in one go. Instead of executing init scripts one after the other as with SysV init, execute a command like the following:

systemctl start <my_1st_service>.service <my_2nd_service>.service

The following table shows a list of the most important service management commands for systemd and SysV init:

start

start

stop

stop

restart

restart

try-restart

try-restart

reload

reload

reload-or-restart

n/a

reload-or-try-restart

n/a

status

status

is-active

status

By default, systemd is not overly verbose. If a service was started successfully, no output will be produced. In case of a failure, a short error message will be displayed. However, systemctl status provides means to debug start-up as well as operation of a service.

systemd comes with its own logging mechanism (« The Journal ») that logs system messages. This allows to display the service messages together with status messages. The status command works similar to tail and can also display the log messages in different formats, making it a powerful debugging tool.

The service management commands mentioned in the previous section let you manipulate services for the current session. systemd also lets you permanently enable or disable services, so they are automatically started when requested or are always unavailable. You can either do this by using YaST, or on the command line.

6.1.3.1. Enabling/Disabling Services on the Command Line¶

The following table shows a list of enabling and disabling commands for systemd and SysV init:

	Service Start
When enabling a service on the command line, it is not started automatically. It is scheduled to be started with the next system start-up or runlevel/target change. In order to immediately start a service after having enabled it, explicitly run systemctl start <my_service>.service or rc<my_service> start.

Tableau 6.2. Commands for Enabling and Disabling Services

Task	systemd subcommand	SysV init subcommand
Enabling	systemctl enable <my_service(s)>.service	insserv <my_service(s)>
Disabling	systemctl disable <my_service(s)>.service	insserv -r <my_service(s)>
Checking Shows whether a service is enabled or not.	systemctl is-enabled <my_service>.service	n/a
Re-Enabling Similar to restarting a service, this commands first disables and then enables a service. Useful to re-enable a service with its defaults.	systemctl reenable <my_service>.service	n/a
Masking When « disabling » a service, it can still be started manually. To completely disable a service, you need to mask it. Use with care.	systemctl mask <my_service>.service	n/a
Unmasking A service that has been masked can only be used again after it has been unmasked.	systemctl unmask <my_service>.service	n/a

6.1.3.2. Enabling/Disabling Services with YaST¶

Start the YaST module with YaST+System+System Services (Runlevel). In the default view, the Simple Mode, it displays an overview listing all the available services and the current status of each service (see Figure 6.1, « System Services (Runlevel) »). The left column shows the name of the service, the center column indicates its current status and the right column gives a short description. For the selected service, a more detailed description is provided in the lower part of the window. To enable a service, select it in the table then select Enable. The same steps apply to disable a service.

The Expert Mode provides detailed control over the runlevels (refer to Section 6.2.1, « Targets vs. Runlevels » for more information on runlevels). The runlevel into which the system boots by default is displayed at the top. Normally it defaults to runlevel 5 (full multiuser mode with network and X). A suitable alternative might be runlevel 3 (full multiuser mode with network). Runlevel 4 is undefined to allow creation of a custom runlevel.

To enable or disable individual services use the table in this window. It lists the services available, shows whether they are currently enabled on your system and, if so, for which runlevels. To define the runlevels in which a service should be started, select the respective row with the mouse and activate the checkboxes below that represent the runlevels. A brief description of the currently selected service or daemon is provided below the table overview.

	Faulty Runlevel Settings May Damage Your System
Faulty runlevel settings may make your system unusable. Before applying your changes, make absolutely sure that you know their consequences.

Figure 6.1. System Services (Runlevel)¶

With Start/Stop/Refresh, decide whether a service should be activated. Refresh status checks the current status. Set/Reset lets you enable or disable a service in the same manner as with the Simple Mode interface. Selecting OK saves the changed settings to disk.

With SysV init the system was booted into a so called « Runlevel ». A runlevel defines how the system is started and what services are available in the running system. Runlevels are numbered, the most commonly known ones are 0 (shutting down the system), 3 (multiuser with network) and 5 (multiuser with network and displaymanager).

systemd introduces a new concept by using so-called « target units ». However, it remains fully compatible to the runlevel concept. Target units are named rather than numbered and serve specific purposes. For example, the targets local-fs.target and swap.target mount local filesystems and swap spaces.

The target graphical.target provides a multiuser system with network and displaymanager capabilities and is equivalent to runlevel 5. Complex targets, such as graphical.target act as « meta » targets by combining a subset of other targets. Since systemd makes it easy to create custom targets by combining existing targets, it offers great flexibility.

The following list shows a list of the most important systemd target units. For a full list refer to man 7 systemd.special.

In order to remain compatible to the SysV init runlevel system, systemd provides special targets named runlevelX.target mapping the corresponding runlevels numbered X.

	systemd Ignores /etc/inittab
The runlevels in a SysV init system are configured in /etc/inittab. systemd does not use this configuration. Please refer to Section 6.2.2, « Custom Targets » for instructions on how to create your own bootable target.

On SysV init SUSE systems, runlevel 4 is unused to allow administrators to create their own runlevel configuration. systemd allows ro create any number of custom targets. It's suggested to start by adapting an existing target such as graphical.target.

	Avoiding Overwritten Customizations
Always do systemd customization in /etc/systemd, never in /lib/systemd. Otherwise your changes will be overwritten by the next update of systemd.

systemd offers means to analyze the system start-up process. You can conveniently review the list of all services and their status (rather than having to parse /varlog/). systemd also allows to scan the start-up procedure to find out how much time each service start-up consumes.

jupiter.example.com: ~ # systemctl
UNIT                                LOAD   ACTIVE SUB       JOB DESCRIPTION
[...]
systemd-random-seed-load.path       loaded active waiting       Random Seed
acpid.service                       loaded active running       ACPI Event Daemon
apache2.service                     loaded failed failed        apache
avahi-daemon.service                loaded active running       Avahi mDNS/DNS-SD Stack
bluez-coldplug.service              loaded active exited        LSB: handles udev coldplug of bluetooth dongles
console-kit...-system-start.service loaded active exited        Console System Startup Logging
cron.service                        loaded active running       Command Scheduler
cups.service                        loaded active running       CUPS Printing Service
[...]
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

107 units listed. Pass --all to see inactive units, too.

jupiter.example.com: ~ # systemctl --failed
UNIT                   LOAD   ACTIVE SUB    JOB DESCRIPTION
apache2.service        loaded failed failed     apache
NetworkManager.service loaded failed failed     Network Manager
plymouth-start.service loaded failed failed     Show Plymouth Boot Screen

[...]

systemd.log_level=debug systemd.log_target=kmsg

dmesg | less

Section 6.1.2, « Debugging Services » explains how to view log messages for given service. However, displaying log messages is not restricted to service logs. You can also access and query the complete log written by systemd—the so-called « Journal ». Use the command systemd-journalctl to display the complete log starting with the oldest entries. Refer to man 1 systemd-journalctl for options such as applying filters or changing the output format.

You can save the current state of systemd to a named snapshot and later revert to it with the isolate subcommand. This is useful when testing services or custom targets, because it allows you to return to a defined state at any time. A snapshot is only available in the current session and will automatically be deleted on reboot. A snapshot name must end in .snapshot.

On a traditional SysV init system it is not always possible to clearly assign a process to the service that spawned it. Some services such as Apache, spawn a lot of 3rd party processes (e.g. CGI or Java processes), which themselves spawn more processes. This makes a clear assignment difficult or even impossible. Additionally, a service may not terminate correctly, leaving some of its children alive.

systemd solves this problem by placing each service into its own cgroup. cgroups are a Kernel feature that allows aggregating processes and all their children into hierarchical organized groups. systemd names each cgroup after its service. Since a non-privileged process it not allowed to « leave » its cgroup, this provides an effective way to label all processes spawned by a service with the name of the service.

To list all processes belonging to a service, use the command systemd-cgls. The result will look like the following (shortened) example:

~ # systemd-cgls --no-pager
├ user
│ └ root
│   └ 1
│     ├ 2279 sshd: root@pts/0
│     ├ 2282 -bash
│     └ 2541 systemd-cgls --no-pager
└ system
  ├ 1 /sbin/init splash showopts
  ├ apache2.service
  │ ├ 2535 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  │ ├ 2536 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  │ ├ 2537 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  │ ├ 2538 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  │ ├ 2539 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  │ └ 2540 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  ├ xdm.service
  │ ├ 2250 /usr/bin/xdm
  │ ├ 2253 /usr/bin/X -nolisten tcp -br vt7 -auth /var/lib/xdm/authdir/authfiles/A:0-ii8Goo
  │ ├ 2263 -:0         
  │ └ 2276 /usr/bin/xconsole -notify -nostdin -verbose -exitOnFail
  ├ ntp.service
  │ └ 2202 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf
  ├ sshd.service
  │ └ 1743 /usr/sbin/sshd -D
    

See Chapitre 10, Kernel Control Groups (↑System Analysis and Tuning Guide) for more information about cgroups.

As explained in Section 6.3.3, « Kernel Control Groups (cgroups) », it is not always possible to assign a process to its parent service process in a SysV init system. This makes it difficult to terminate a service and all of its children. Child processes that have not been killed will remain as zombie processes.

systemd's concept of to confine each service into a cgroup makes it possible to clearly identify all child processes of a service and therefore allows to send a signal to each of these processes. Use systemctl kill to send signals to services. For a list of available signals refer to man 7 signals.