In order to gain proficiency in Ubuntu system administration it is important to understand the concepts of systemd units with a particular emphasis on two specific types known as targets and services. The goal of this chapter, therefore, is to provide a basic overview of the different systemd units supported by Ubuntu combined with an overview of how to configure the many services that run in the background of a running Linux system.
1.1 Understanding Ubuntu systemd Targets
Ubuntu can be configured to boot into one of a number of states (referred to as targets), each of which is designed to provide a specific level of operating system functionality. The target to which a system will boot by default is configured by the system administrator based on the purpose for which the system is being used. A desktop system, for example, will most likely be configured to boot using the graphical user interface target, while a cloud-based server system would be more likely to boot to the multi-user target level.
During the boot sequence, a process named systemd looks in the /etc/systemd/system folder to find the default target setting. Having identified the default target, it proceeds to start the systemd units associated with that target so that the system boots with all the necessary processes running. For those familiar with previous Ubuntu versions, systemd targets are the replacement for the older runlevel system.
1.2 Understanding Ubuntu systemd Services
A service is essentially a process, typically running in the background, that provides specific functionality. The sshd service, for example, is the background process (also referred to as a daemon) that provides secure shell access to the system. Different systemd targets are configured to automatically launch different collections of services, depending on the functionality that is to be provided by that target. Targets and services are types of systemd unit, a topic which will be covered later in this chapter.
1.3 Ubuntu systemd Target Descriptions
As previously outlined, Ubuntu can be booted into one of a number of target levels. The default target to which the system is configured to boot will, in turn, dictate which systemd units are started. The targets that relate specifically to system startup and shutdown can be summarized as follows:
- poweroff.target – This is the target in which the system shuts down. For obvious reasons it is unlikely you would want this as your default target.
- rescue.target – Causes the system to start up in a single user mode under which only the root user can log in. In this mode the system does not start any networking, graphical user interface or multi-user services. This run level is ideal for system administrators to perform system maintenance or repair activities.
- multi-user.target – Boots the system into a multi-user mode with text based console login capability.
- graphical.target – Boots the system into a networked, multi-user state with X Window System capability. By default the graphical desktop environment will start at the end of the boot process. This is the most common run level for desktop or workstation use.
- reboot.target – Reboots the system. Another target that, for obvious reasons, you are unlikely to want as your default.
In addition to the above targets, the system also includes about 70 other targets, many of which are essentially sub-targets used by the above main targets. Behind the scenes, for example, multiuser.target will also start a target named basic.target which will, in turn, start the sockets.target unit which is required for communication between different processes. This ensures that all of the services on which the multi-user target is dependent are also started during the boot process.
A list of the targets and services on which a specified target is dependent can be viewed by running the following command in a terminal window:
# systemctl list-dependencies <target>
Figure 11-1, for example, shows a partial listing of the systemd unit dependencies for the multiuser target (the full listing contains over 120 targets and services required for a fully functional multi-user system):
The listing is presented as a hierarchical tree illustrating how some dependencies have subdependencies of their own. Scrolling to the bottom of the list, for example, would reveal that the multi-user target depends on local-fs.target with its own service and target sub-dependencies:
The colored dots to the left of each entry in the list indicate the current status of that service or target as follows:
- Green – The service or target is active and running.
- White – The service or target is inactive (dead). Typically because the service or target has not yet been enabled, has been stopped for some reason, or a condition on which the service or target depends has not been met.
- Red – The service or target failed to start due to a fatal error.
To find out more details about the status of a systemd unit, use the systemctl status command followed by the unit name as follows:
# systemctl status systemd-machine-id-commit.service ◉ systemd-machine-id-commit.service - Commit a transient machine-id on disk Loaded: loaded (/usr/lib/systemd/system/systemd-machine-id-commit.service; static; vendor preset: disabled) Active: inactive (dead) Condition: start condition failed at Thu 2019-02-14 15:27:47 EST; 1h 14min ago ConditionPathIsMountPoint=/etc/machine-id was not met Docs: man:systemd-machine-id-commit.service(8)
1.4 Identifying and Configuring the Default Target
The current default target for an Ubuntu system can be identified using the systemctl command as follows:
# systemctl get-default multi-user.target
In the above case, the system is configured to boot using the multi-user target by default. The default setting can be changed at any time using the systemctl command with the set-default option. The following example changes the default target to start the graphical user interface the next time the system boots:
# systemctl set-default graphical.target Removed /etc/systemd/system/default.target. Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/ graphical.target.
The output from the default change operation reveals the steps performed in the background by the systemctl command to implement the change. The current default is configured by establishing a symbolic link from the default.target file located in /etc/systemd/system to point to the corresponding target file located in the /usr/lib/systemd/system folder (in this case the graphical.target file).
1.5 Understanding systemd Units and Unit Types
As previously mentioned, targets and services are both types of systemd unit. All of the files within the /usr/lib/systemd/system folder are referred to as systemd unit configuration files, each of which represents a systemd unit. Each unit is, in turn, categorized as being of a particular unit type. Ubuntu supports 12 different unit types including the target and service unit types already covered in this chapter.
The type of a unit file is represented by the filename extension as outlined in Table 11-1 below:
|Unit Type||Filename Extension||Type Description|
|Target||.target||Group of systemd units.|
|Automount||.automount||File system auto-mount point.|
|Device||.device||Device file recognized by the kernel.|
|Mount||.mount||File system mount point.|
|Path||.path||File or directory in a file system.|
|Scope||.scope||Externally created process.|
|Slice||.slice||Group of hierarchically organized units that manage system processes.|
|Snapshot||.snapshot||Saved state of the systemd manager.|
|Socket||.socket||Inter-process communication socket.|
|Swap||.swap||Swap device or a swap file.|
Note that the target unit type differs from other types in that it is essentially comprised of a group of systemd units such as services or other targets.
1.6 Dynamically Changing the Current Target
The systemctl set-default command outlined previously specifies the target that will be used the next time the system starts, but does not change the state of the currently running system. To change to a different target dynamically, use the systemctl command once again, this time using the isolate option followed by the destination target. To switch the current system to the graphical target without rebooting, for example, the following command would be used:
# systemctl isolate graphical.target
Once executed, the system will start the graphical desktop environment.
1.7 Enabling, Disabling and Masking systemd Units
A newly installed Ubuntu system will include the base systemd service units but is unlikely to include all of the services that will eventually be needed by the system once it goes into a production environment. A basic Ubuntu installation, for example, will typically not include the packages necessary to run an Apache web server, a key element of which is the apache2.service unit.
The system administrator will resolve this problem by installing the necessary Apache packages using the following command:
# apt install apache2
Having configured the web server, the next task will be to check the status of the apache2 service unit to identify whether it was activated as part of the installation process:
# systemctl status apache2.service ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: active (running) since Wed 2020-04-08 14:34:54 EDT; 34s ago Main PID: 3513 (apache2) Tasks: 55 (limit: 4915) CGroup: /system.slice/apache2.service ├─3513 /usr/sbin/apache2 -k start ├─3515 /usr/sbin/apache2 -k start └─3516 /usr/sbin/apache2 -k start
As we can see from the above output, the apache2 service is already loaded and active without having to be manually started. This is because the vendor preset is set to enable to ensure the service starts after installation is complete.
A currently running service may be stopped at any time as follows:
# systemctl stop apache2.service
Because the service is listed as enabled in the status output, the next time the system reboots to the current target, the apache2 service will start automatically. Assuming, for example, that the service was enabled while the system was running the multi-user target, the apache2 service will have been added as another dependency to the multi-user.target systemd unit.
Behind the scenes, systemctl adds dependencies to targets by creating symbolic links in the .wants folder for the target within the /etc/systemd/system folder. The multi-user.target unit, for example, has a folder named multi-user.target.wants in /etc/systemd/system containing symbolic links to all of the systemd units located in /usr/lib/systemd/system on which it is dependent. A review of this folder will show a correlation with the dependencies listed by the systemctl list-dependencies command outlined earlier in the chapter.
To disable a service so that it no longer starts automatically as a target dependency, simply disable it as follows:
# systemctl disable apache2.service
This command will remove the symbolic link to the apache2.service unit file from the .wants directory so that it is no longer a dependency and, as such, will not be started the next time the system boots.
The .wants folder contains dependencies which, if not available, will not prevent the unit from starting and functioning. Mandatory dependencies (in other words dependencies that will cause the unit to fail if not available) should be placed in the .requires folder (for example multi-user. target.requires).
In addition to enabling and disabling, it is also possible to mask a systemd unit as follows:
# systemctl mask apache2.service
A masked systemd unit cannot be enabled, disabled or started under any circumstances even if it is listed as a dependency for another unit. In fact, as far as the system is concerned, it is as though a masked systemd unit no longer exists. This can be useful for ensuring that a unit is never started regardless of the system conditions. The only way to regain access to the service is to unmask it:
# systemctl unmask apache2.service
1.8 Working with systemd Units in Cockpit
In addition to the command-line techniques outlined so far in this chapter, it is also possible to review and manage systemd units from within the Cockpit web-based interface. Assuming that Cockpit has been installed and set up as outlined in the chapter entitled ”An Overview of the Ubuntu Cockpit Web Interface”, access to the list of systemd units on the system can be accessed by logging into Cockpit and selecting the Services option in the left-hand navigation panel marked A in Figure 11-3:
The button marked B displays units of specific types in the main area marked C where the current status of each unit is listed in the State column.
Selecting a unit from the list will display detailed information. Figure 11-4, for example, shows the detail screen for an apparmor.service instance including service logs (A) and menu options (B) for performing tasks such as starting, stopping, enabling/disabling and masking/unmasking the unit.
A newly installed Ubuntu system includes a base set of systemd units many of which run in the background to provide much of the functionality of the system. These units are categorized by type, the most common of which being targets and services. A target unit is simply a group of other units that are to be started collectively. The system has a default target unit which defines the other units which are to be started up each time the system boots. The most common targets are those which boot the system to either multi-user or graphical mode. The systemctl command-line tool provides a range of options for performing systemd unit configuration tasks, many of which are also available through the Cockpit web-based interface.