Introduction
In this lab, you will learn how to check if a system service is masked in Linux using systemd. Masking a service prevents it from starting, which is a key concept for system management and troubleshooting. You will use the systemctl is-masked command to check the mask status of specific services and the systemctl list-unit-files command to get a broader overview of systemd unit files. Finally, you will explore the systemd configuration directories to understand where these settings are stored.
Check service mask with systemctl is-masked
In this step, we'll start exploring systemd, the system and service manager in modern Linux distributions like Ubuntu. systemd is responsible for starting, stopping, and managing services (like web servers, databases, etc.) and other system resources.
One important concept in systemd is "masking" a service. Masking a service prevents it from being started, even manually or by other services. This is a way to completely disable a service.
We can check if a service is masked using the systemctl is-masked command. Let's check the status of a common service, apache2. Apache is a popular web server.
Open your terminal if it's not already open. Remember, you can find the Xfce Terminal icon on the left side of your desktop.
Type the following command and press Enter:
systemctl is-masked apache2
You should see output similar to this:
inactive
This output indicates that the apache2 service is not masked. If it were masked, the output would be masked.
Let's try checking a service that is typically masked by default in this environment, like systemd-udevd-kernel.socket. This is a low-level system service.
Type the following command and press Enter:
systemctl is-masked systemd-udevd-kernel.socket
The output should be:
masked
This confirms that the systemd-udevd-kernel.socket service is indeed masked.
Understanding whether a service is masked is crucial for troubleshooting and managing your system. If a service isn't starting, checking its masked status is often one of the first steps.
Click Continue to proceed to the next step.
List unit files with systemctl list-unit-files
In the previous step, we used systemctl is-masked to check the status of individual services. Now, let's get a broader view of all the unit files that systemd knows about.
systemd manages various types of "units," which are configuration files that define services, mount points, devices, sockets, and more. The most common type is the .service unit, which defines how to run a background process (a service).
The systemctl list-unit-files command displays a list of all installed unit files and their "enable" state. The enable state indicates whether a unit is configured to start automatically at boot time.
Type the following command in your terminal and press Enter:
systemctl list-unit-files
This command will output a long list of unit files. The output will look something like this (only a small portion is shown):
UNIT FILE STATE
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.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
sys-kernel-tracing.mount static
...
apache2.service disabled
...
The output has two columns:
UNIT FILE: The name of the unit file (e.g.,apache2.service).STATE: The enable state of the unit (e.g.,static,enabled,disabled,masked).
Here's a brief explanation of some common states:
enabled: The unit is configured to start automatically at boot.disabled: The unit is not configured to start automatically at boot.static: The unit cannot be enabled or disabled; its startup is controlled by another unit.masked: The unit is completely disabled and cannot be started.
You can scroll through the output using your terminal's scrollbar or by piping the output to a pager like less. For example:
systemctl list-unit-files | less
Inside less, you can use the arrow keys to scroll, press spacebar to go down a page, and press q to exit.
This command is very useful for seeing what services are installed on your system and how they are configured to start.
Click Continue to move on.
Inspect systemd config in /etc/systemd
In the previous steps, we used the systemctl command to interact with systemd. Now, let's look at where systemd stores its configuration files.
The primary directory for systemd configuration files is /etc/systemd. This directory contains subdirectories for different types of unit files and configuration settings.
Let's list the contents of the /etc/systemd directory using the ls command. Remember, /etc is a standard directory in Linux for configuration files.
Type the following command in your terminal and press Enter:
ls /etc/systemd/
You will see a list of directories and files, similar to this:
journald.conf logind.conf networkd.conf resolved.conf system system.conf timesyncd.conf user user.conf
The most important subdirectory here is /etc/systemd/system. This is where system-wide unit files are often placed or linked to. Let's look inside this directory.
Change your current directory to /etc/systemd/system using the cd command.
cd /etc/systemd/system
Now, list the contents of this directory:
ls
You'll see a list of files and directories, many of which are symbolic links (->) pointing to the actual unit files located elsewhere (often in /lib/systemd/system). This is how services are enabled or disabled – by creating or removing these symbolic links.
For example, you might see something like:
multi-user.target.wants -> /lib/systemd/system/multi-user.target.wants
sockets.target.wants -> /lib/systemd/system/sockets.target.wants
...
The .wants directories contain symbolic links to services that should be started when that target is reached. For instance, multi-user.target.wants contains links to services that should run when the system is in a multi-user state (like after booting up).
Let's look inside the multi-user.target.wants directory.
ls multi-user.target.wants/
You'll see a list of services that are enabled to start in the multi-user target.
anacron.service -> ../anacron.service
apache2.service -> ../../apache2.service
...
This shows that apache2.service is linked here, meaning it's enabled to start with the multi-user target.
Exploring the /etc/systemd/system directory helps you understand how systemd organizes and manages the services on your system.
Click Continue to finish this lab.
Summary
In this lab, we began exploring systemd in Linux, focusing on how to determine if a system service is "masked." Masking a service is a method to completely disable it, preventing it from starting under any circumstances. We learned to use the systemctl is-masked command to check the masked status of specific services, observing that apache2 was not masked while systemd-udevd-kernel.socket was. Understanding the masked status is a fundamental step in troubleshooting service startup issues.
We then moved on to using systemctl list-unit-files to gain a broader perspective of all the unit files managed by systemd, which are configuration files representing various system resources and services. This command provides a comprehensive list of units and their states, offering a wider view of the system's configuration beyond individual service checks.
