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

systemd allows to manage several services in one go. So instead of executing init scripts one after the other as with SysV init, you can 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

	Verbosity
systemd is not overly verbose. If a command was executed successful, no output will be produced. In case of a failure, an error message will be displayed.

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 startup as well as operation of a service.

systemd comes with it's 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 always get automatically started when requested or are always unavailable. You can either do this by using the YaST module System Services (Runlevel) which acts as a consistent frontend for both systemd and SysV init, 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, but rather scheduled to be started with the next system startup or runlevel/target change. In order to immediately start a service after having enabled it, you need to explicitly run systemctl start <my_service>.service or rc<my_service> start.

Tabelle 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¶

After starting this YaST module with YaST+System+System Services (Runlevel), it displays an overview listing all the available services and the current status of each service (disabled or enabled). Decide whether to use the module in Simple Mode or in Expert Mode. The default Simple Mode should be sufficient for most purposes. 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.

For detailed control over the runlevels in which a service is started or stopped or to change the default runlevel, first select Expert Mode. The current default runlevel or „initdefault“ (the runlevel into which the system boots by default) is displayed at the top. Normally, the default runlevel of a openSUSE system is runlevel 5 (full multiuser mode with network and X). A suitable alternative might be runlevel 3 (full multiuser mode with network).

This YaST dialog allows the selection of one of the runlevels as the new default. Additionally, use the table in this window to enable or disable individual services and daemons. The table lists the services and daemons available, shows whether they are currently enabled on your system and, if so, for which runlevels. After selecting one of the rows with the mouse, click the check boxes representing the runlevels to define the runlevels in which the selected service or daemon should be running. Runlevel 4 is undefined to allow creation of a custom runlevel. 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.

Abbildung 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. The targets local-fs.target and swap.target, for example, mount local filesystems and swap spaces.

Complex targets, such as graphical.target (acts as an equivalent to runlevel 5 and provides multiuser with network and displaymanager capabilities) 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.

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:

	Customization
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 startup 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 startup procedure to find out how much time each service startup 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

[...]

In Abschnitt 6.1.2, „Debugging Services“ we have explained 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 the systemd System Manager to a named snapshot and later return 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 and make a clear assignment difficult or even impossible. Whats more, a service may not terminate correctly, leaving some of its children alive.

systemd solves this problem by placing each service into it's 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 Chapter 10, Kernel Control Groups (↑System Analysis and Tuning Guide) for more information about cgroups.

As explained in Abschnitt 6.3.4, „Killing Services (Sending Signals)“, it is not always possible to assign a process to its parent service process in a SysV init system. This makes it difficult to, for example, 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.