Introduction
Systemd is a system manager and provisioning system that has become the new standard for Linux distributions. Familiarity with systemd is recommended due to their sophisticated adaptability, as it will substantially simplify server administration. Learning and utilizing the systemd tools and daemons managing can help you appreciate the advantages and flexibility it provides, or at the very least work with as few difficulties as possible.
We’ll go over managing services, checking status, changing system status, and working with configuration files.
While systemd has become the default provisioning system for many Linux distributions, it is not used in all of them. If your terminal displays the error bash: systemctl is not installed, it is likely that another provisioning system is installed on your machine.
Management of services
The provisioning system’s basic goal is to initialize the components that will be launched when the Linux kernel is booted (traditionally called userland components). The provisioning system is also used to handle server services and daemons at all times the system is operational. With this in mind, we’ll begin with a few fundamental procedures for managing services.
Most operations in systemd are directed at “modules,” which are resources that systemd understands how to handle. Modules are classified according to the type of resource they represent and are described by files called module files. The suffix at the end of the file indicates the kind of each module.
The target module for service management tasks will be service modules with module files ending in.service. However, you may not want to use the.service suffix for most service management tasks because systemd is smart enough to recognize that you may want to work with service when using service management commands.
Systemd setup and closure
Use the start command to start the systemd service according to the instructions in the service module file. If you are not a root user, you must use sudo because this affects the operating system state:
sudo systemctl start application.service
As previously stated, systemd will seek for *.service files when looking for service management commands, therefore the command can be readily input as follows.
sudo systemctl start application
Although the above style can be used for general administration, we will use the.service suffix for the rest of the commands to make it obvious what we are working on.
You can use the stop command to halt a currently operating service:
sudo systemctl stop application.service
Service restarting and rebooting
Use the start command to start the systemd service according to the instructions in the service module file. If you are not a root user, you must use sudo because this affects the operating system state:
sudo systemctl restart application.service
As previously stated, systemd will seek for *.service files when looking for service management commands, therefore the command can be readily input as follows.
sudo systemctl reload application.service
Although the above style can be used for general administration, we will use the.service suffix for the rest of the commands to make it obvious what we are working on.
You can use the stop command to halt a currently operating service:
sudo systemctl reload-or-restart application.service
Service activation and deactivation
The commands listed above are useful for launching and terminating services during the current session. These must be enabled in order for systemd to start services automatically at boot.
To start the service at boot time, use the enable command:
sudo systemctl enable application.service
This will build a symbolic link from a system copy of the service file (often in /lib/systemd/system or /etc/systemd/system) to the directory on disk where systemd looks for autorun files (typically /etc/systemd/system/some target.target.wants; we will look at target later in this manual).
To prevent the service from starting automatically, type:
sudo systemctl disable application.service
This will remove the symbolic link that indicates the service should not start automatically.
Keep in mind that allowing the service does not initiate it in the current session. If you want to start and activate the service at boot, you must issue both commands, start and enable.
Monitoring the status of services
You can use the status command to check the status of a service on your system:
systemctl status application.service
This will offer you the service’s status, a control group hierarchy, and the first few lines of the logbook.
When checking the status of the Nginx server, for example, you may receive the following output:
Output
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
Main PID: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
└─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server...
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.
This offers you a good overview of the application’s current status and tells you if there are any issues or if you need to take any action.
There are various methods for verifying specific statuses. To see if a module is currently active (in use), use the is-active command:
systemctl is-active application.service
This will return the module’s current status, which is generally active or inactive. If activated, the output code will be “0,” making the result easier to interpret into shell scripts.
To determine whether a module is enabled, use the is-enabled command:
systemctl is-enabled application.service
This will output if the service is enabled or disabled and, based on the command question, will set the output code to “0” or “1.”
The third check is to see if the module has failed. This indicates that there was an issue that caused the module in question to be activated:
systemctl is-active application.service
This will return active if everything is well, or failed if an error occurred. If the module was halted on purpose, it may return unknown or inactive. An output status of “0” denotes a failure, while an output status of “1” indicates another status.
Overview of the system’s status
So far, the commands have been useful for managing individual services, but not for knowing the present condition of the system. This information is provided by a number of systemctl commands.
Current Modules List
You can use the list-units command to see a list of all active modules that systemd is aware of:
ystemctl list-units
This will display a list of all the modules that are currently active on the system. The end result will look like this:
Output
UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running ATD daemon
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack
dbus.service loaded active running D-Bus System Message Bus
dcron.service loaded active running Periodic Command Scheduler
dkms.service loaded active exited Dynamic Kernel Modules System
getty@tty1.service loaded active running Getty on tty1
The following columns appear in the output:
UNIT: name of a systemd module
LOAD: shows if the module configuration was parsed by systemd. The loaded modules’ configuration is saved in memory.
ACTIVE: a summary of the module’s activity. This is a fairly standard approach of determining whether or not a module is running.
SUB: a lower level state indicating more detailed information about the module. It frequently depends on the module’s type, status, and actual mode of operation.
DESCRIPTION: a brief written explanation of what the module is and what it does.
Because the list-units command by default only displays active modules, all of the entries above will show loaded in the LOAD column and active in the ACTIVE column. This is the default behavior of the systemctl when invoked without any additional commands, therefore you will see the same thing as when you invoke the systemctl without any arguments:
systemctl
By passing additional flags to systemctl, we can output various information. For example, we can use the flag —all to list all the modules that systemd has loaded (or attempted to load), regardless of their present activity:
systemctl list-units --all
This will show all modules that systemd has loaded or attempted to load, independent of the system’s current state. After work, certain modules become dormant, and some modules that systemd attempted to load may not be found on disk.
Other flags can be used to filter these results. For example, we can use the —state= parameter to specify whether we want to observe the LOAD, ACTIVE, or SUB state. You must keep the —all flag set in order for systemctl to display inactive modules:
systemctl list-units --all --state=inactive
The —-type= filter is another frequent filter. We can tell systemctl to only show modules of the type we want. To display only active service modules, use:
systemctl list-units --type=serviceAll module files
The list-units command only lists the modules that systemd attempted to parse or load into memory. Because systemd will only read the modules it deems required, this will not necessarily be all modules accessible on the system. You can use the list-unit-files command to see all accessible module files in the systemd paths, including those that systemd has attempted to load:
systemctl list-unit-files
Modules are representations of resources that systemd is aware of. Because systemd does not always read all of the module definitions in this view, it just displays information on the files themselves. The output includes two columns: the module file and the status.
Output
UNIT FILE STATE
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount static
var-lib-nfs-rpc_pipefs.mount static
org.cups.cupsd.path enabled
. . .
In most cases, the status will be enabled, disabled, static, or disguised. In this context, static means that the module file lacks an install section that is needed to enable the module. These modules cannot be enabled as is. Typically, this signifies that the module is only used as a dependency on another module and should not operate on its own.
Module administration in Systemd
So far, we’ve worked with services to provide information about modules and module files known to systemd. However, by using some additional commands, we may obtain more particular information about the modules.
The module file is being displayed.
The cat command can be used to see the module file that systemd has loaded on your system (it was added in systemd version 209). For example, to view the module file of the atd scheduler daemon, type :
systemctl cat atd.service
Output
[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target
Gives out he module file known to the currently running systemd process. This is useful if you have recently edited the module files or if you override specific options in a module file fragment (we’ll go over this later).
Systemd display of Dependency
The list-dependents command can be used to view a module’s dependencies tree:
systemctl list-dependencies sshd.service
This will show a hierarchical scheme of dependencies that must be dealt with in order for the module of interest to run. Dependencies in this sense refer to modules that are either required or desired by the modules mentioned above.
Output
sshd.service
├─system.slice
└─basic.target
├─microcode.service
├─rhel-autorelabel-mark.service
├─rhel-autorelabel.service
├─rhel-configure.service
├─rhel-dmesg.service
├─rhel-loadmodules.service
├─paths.target
├─slices.target
. . .
Only .target modules that define system state have recursive dependencies displayed. Add the —all flag , to recursively list all dependents.
You can use the —reverse flag to reveal reverse dependencies (modules that depend on the specified module). Other relevant flags are —before and —after, which can be used to display modules that are dependent on the specified module before and after.
Examining module attributes in systemd
The show command can be used to view the properties of a lower-level module. This will provide a list of the attributes declared for the selected module in the key=value format:
systemctl show sshd.service
Output
Id=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon
. . .
If you just want to display a single property, use the -p flag along with the property name. For example, to view the conflicts in the sshd.service module, type the following:
systemctl show sshd.service -p Conflicts
Output
Conflicts=shutdown.target
Systemd modules for masking and unmasking
We learnt how to halt or deactivate a service in the services management section, but systemd also has the ability to mark a module as fully unrunable, either automatically or manually, by associating it with /dev/null. This is known as module masking, and it is possible with the mask command:
sudo systemctl mask nginx.service
While the Nginx service is hidden, it cannot be started automatically or manually.
If you look in list-unit-files, you’ll notice that the service is now marked as masked:
systemctl list-unit-files
Output
. . .
kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service static
nginx.service masked
quotaon.service static
rc-local.service static
rdisc.service disabled
rescue.service static
. . .
If you attempt to launch the service, you will receive the following message:
sudo systemctl start nginx.service
Output
Failed to start nginx.service: Unit nginx.service is masked.
Use the unmask command to unmask a module and make it available for use again:
sudo systemctl unmask nginx.service
This restores the module’s prior state, allowing it to be started or switched on.
Module file editing in systemd
Although the format of module files is beyond the scope of this document, systemctl includes tools for editing and updating module files when changes are required. Systemd version 218 now has this capability.
The edit command by default will open the module file fragment for the module of interest:
sudo systemctl edit nginx.service
This file will be empty and can be used to override or add directives to the module specification. In /etc/systemd/system, a directory with the module name and.d appended will be created. For example, nginx.service will generate a directory called nginx.service.d.
In this directory, a file called override.conf will be produced. Systemd will link the override fragment to the whole module file in memory when the module is loaded. The directives in the sample will override those in the original module file.
You can use the —full flag to change the entire module file rather than just a fragment:
sudo systemctl edit --full nginx.service
This will open the current module file in the editor for editing. After you exit the editor, the updated file will be written to /etc/systemd/system, where it will take precedence over the system module definition (which is ordinarily found in /lib/systemd/system).
To remove any changes, delete the.d module configuration directory or the changed service file from /etc/systemd/system. To delete a fragment, use the following command:
sudo rm -r /etc/systemd/system/nginx.service.d
In order to erase the entire altered module file:
sudo rm /etc/systemd/system/nginx.service
After removing a file or directory, restart the systemd process so that it no longer attempts to refer to these files and instead uses system copies. Enter the following command to accomplish this:
sudo systemctl daemon-reload
Using targets to change the system state (trigger level)
Targets are special module files that describe the current state of the system or a synchronisation point. Files that define targets, like other modules, can be identified by a suffix, which in this case is.target. Targets have little meaning on their own, but they are used to combine other modules together.
They can be utilized in the same manner that other initialisation systems use trigger levels to get the system into various states. When particular functions are available, they are utilized as a reference, allowing you to describe a desired state rather than needing to employ different modules to retrieve that state.
Swap.target, for example, is used to indicate that a switch is ready for use. Modules in this process can synchronize for this purpose by specifying WantedBy= or RequiredBy= swap.target in their configuration. Modules that require the ability to switch can express this state by indicating the nature of their relationship with the requirements Wants=, Requires=, and After=.
Identifying and configuring a default target
When the system boots, the systemd process uses a default target. Satisfying a series of dependencies on this single goal will result in the system reaching the desired state. Type systemctl get-default to get your system’s default target.
systemctl get-default
Output
multi-user.target
If you want to change the default target, use set-default. For instance, if you have a graphical desktop installed and want the system to boot into that by default, you can alter the default target with following sudo command:
sudo systemctl set-default graphical.target
Targets that are currently available in systemd
Enter systemctl list-unit-files —type=target to get a list of available targets on your system:
systemctl list-unit-files --type=target
Multiple targets can be active at the same time, unlike initial levels. An active target indicates that systemd attempted to start all modules attached to the target but did not succeed. Type this to see all active targets:
systemctl list-units --type=target
Identifying and isolating targets
All modules associated with a target can be started, and all modules that are not part of the dependency tree can be stopped. The command necessary to accomplish this is appropriately named isolate. Changing the startup level in other initialisation systems is analogous.
If you are working in a graphical environment and have graphical.target active, you can terminate the graphical system and switch to a multi-user command line state by isolating multi-user.target. All graphical modules will be terminated since graphical.target is dependent on multi-user.target and not vice versa.
Before doing this method, you should examine the target dependencies you are isolating to ensure that critical services are not disrupted:
systemctl list-dependencies multi-user.target
If you are happy with the modules that will be kept active, you can isolate the target by running:
sudo systemctl isolate multi-user.target
For crucial events, use the rapid input combination.
Important events, such as shutdown or reboot, have targets configured. There are, however, a number of rapid input combinations for systemctl that provide additional functionality.
For example, instead of isolate rescue, you may use the rescue command to place the system into rescue mode (one user):
sudo systemctl rescue
This will provide an extra function to notify all connected users of the event.
You can use the halt command to stop the system:
sudo systemctl halt
To force a complete shutdown, use the poweroff command:
sudo systemctl poweroff
The reboot command can be used to initiate a restart:
sudo systemctl reboot
All of this will notify connected users that an event is taking place; something that simply executes or isolates the target will not function. It should be noted that in order for these actions to operate effectively with systemd, most machines will bind shorter, more typical instructions.
For example, to restart the system, typically enter the following:
sudo reboot
If you are happy with the modules that will be kept active, you can isolate the target by running:
sudo systemctl isolate multi-user.target
Conclusion
You should be familiar with some of the basic functions of the systemctl command, which allows you to interface with and control a systemd instance, at this point. The systemctl utility will serve as the primary interface for managing services and system status.
Although systemctl is primarily responsible for the primary systemd process, various components of the systemd ecosystem are managed by other tools. Log management and user sessions, for example, are handled by different daemons and management programs (journald/journalctl and logind/loginctl, respectively). Understanding these other tools and daemons will help with management.
