What are the two system initialization processes utilized by linux to load and manage services?

You need to know if your Linux distribution uses systemd or something else.

Look for the /run/systemd/system/ directory. If this exists, then your init system is systemd.

The /run/systemd/ directory may be present on your system if your distribution supports multiple init systems. But systemd is not the active init unless you see /run/systemd/system/.

There are several other ways to learn which init system your system is using. Try querying /sbin/init. Originally this was the SysV executable, and now most Linux distributions preserve the name and symlink it to the systemd executable. This example confirms that the init is systemd:

On a system using SysV init, it has no symlink:

The /proc pseudofilesystem is an interface to your Linux kernel, and contains the current state of a running system. It is called a pseudofilesystem because it exists only in memory and not on disk. In this example, /proc/1/exe is symlinked to the systemd executable:

On a SysV system, it links to init:

The /proc/1/comm file reports your active init system:

On a SysV system, it reports init:

The command attached to process ID (PID) 1 is your init. PID 1 is the first process launched at startup, which then starts all other processes. You can see this with the ps command:

When the init is SysV, it looks like this:

See Recipe 4.2 for more information on PID 1.

Linux support for systemd varies. Most of the major Linux distributions have adoped systemd, including Fedora, Red Hat, CentOS, openSUSE, SUSE Linux Enterprise, Debian, Ubuntu, Linux Mint, Arch, Manjaro, Elementary, and Mageia Linux.

Some popular distributions that do not support systemd, or include it but not as the default init, are Slackware, PCLinuxOS, Gentoo Linux, MX Linux, and antiX.

• Distrowatch for information on hundreds of Linux distributions

• man 5 proc

• man 1 pstree

• man 1 ps

You want to list all services installed on your system, and you want to know the states of the services: whether they are running, not running, or in an error state.

systemctl, the systemd manager command, tells all. Run it with no options to see a detailed list of all loaded units. A systemd unit is any related batch of processes defined in a unit configuration file and managed by systemd:

This prints a giant pile of information: 177 active loaded units on my test system with the full unit names, status, and long descriptions. Redirect the the output to a text file for easier study:

Treat yourself to more information overload by listing all units, active and inactive:

This results in 349 loaded units listed on my test system, including not-found and inactive units. How many total unit files? The following example shows 5 out of 322:

We are interested in service files because Linux users and administrators interact mainly with service files and rarely need to bother with any other type of unit file. How many are installed? Let’s see:

The preceding example displays the four most common states that a service can be in: enabled, disabled, static, or masked.

List only enabled services:

List only disabled services:

List only static services:

List only masked services:

Service unit files are in /usr/lib/systemd/system/ or /lib/systemd/system/, according to where your Linux distribution puts them. These are plain-text files you can read.

This shows that the service has become available and is managed by systemd. When a service is enabled, systemd creates a symlink in /etc/systemd/system/ from the unit file in /lib/systemd/system/. It can be started, stopped, reloaded, and disabled by the user with the systemctl command.

Enabling a service does not immediately start it, and disabling a service does not immediately stop it (see Recipe 4.6).

Diabled means that there is no symlink in /etc/systemd/system/, and it will not start automatically at boot. You can stop and start it manually.

This means the service is linked to /dev/null/. It is completely disabled and cannot be started by any means.

This means that the unit file is a dependency of other unit files, and cannot be started or stopped by the user.

Some less-common service states you will see:

Indirect states belong to services that are not meant to be managed by users, but are meant to be used by other services.

Generated states indicate that the service has been converted from a nonnative systemd initialization configuration file, either SysV or LSB init.

You want to know the status of one service or a few specific services.

systemctl status provides a nice little bundle of useful status information. The following example queries the CUPS service. CUPS, the Common Unix Printing System, should be on all Linux systems:

Query multiple services with a space-delimited list:

There is a lot of useful information in this little bit of output (Figure 4-2).

The dot next to the service name is a quick status indicator. It appears in colors on most terminals. White is an inactive or deactivating state. Red is a failed or error state. Green indicates an active, reloading, or activating state. The rest of the information in the output is described in the following:

Verifies that the unit file has been loaded into memory, displays its full path, the service is enabled (see the Discussion about states in Recipe 4.3), and vendor preset: disabled/enabled indicates if the installation default is to start at boot or not. When it is disabled, the vendor default is to not start at boot. This only shows the vendor preference and does not indicate if it is currently enabled or disabled.

Tells you if the service is active or inactive, and how long it has been in that state.

Reports the PIDs and their commands and daemons.

This is the process number for the cgroup slice.

Reports how many tasks the service has started. Tasks are PIDs.

Shows which unit slice the service belongs to and its PID. The three default unit slices are user.slice, system.slice, and machine.slice.

Linux control groups (cgroups) are sets of related processes and all of their future children. In systemd, a slice is a subdivision of a cgroup, and each slice manages a particular group of processes. Run systemctl status to see a diagram of the cgroup hierarchy.

By default, service and scope units are grouped in /lib/systemd/system/system.slice.

User sessions are grouped in /lib/systemd/system/user.slice.

Virtual machines and containers registered with systemd are grouped in /lib/systemd/system/machine.slice.

The remaining lines are the most recent log entries from journalctl, the systemd log manager.

You want to stop and start services with systemd.

This is a job for systemctl. The following examples use the SSH service to demonstrate service management.

Start a service:

Stop a service:

Stop and then restart a service:

Reload the service’s configuration. For example, you made a change to sshd_config and want to load the new configuration without restarting the service:

All of these commands also work with multiple services, space-delimited, for example:

If you’re curious about the commands that systemd runs behind the scenes to start, reload, or stop the individual daemons, look in their unit files. Some services have start, reload, stop, and other instructions in their unit files, like this example for httpd:

You don’t have to do anything special with this information; it is there when you want to know how systemctl is managing a particular service.

• Recipe 4.6

• man 1 systemctl

You want a service or services to automatically start at boot, or you want to prevent a service from starting at boot, or to disable it completely.

Enabling a service configures it to automatically start at boot.

Disabling a service stops it from starting at boot, but it can be started and stopped manually.

Masking a service disables it so that it cannot be started at all.

The following example enables the sshd service:

The output shows that enabling a service means creating a symlink from the service file in /lib/systemd/system/ to /etc/systemd/system/. This does not start the service. You can start the service with systemctl start, or enable and start the service in one command with the --now option:

This command disables the sshd service. It does not stop the service, so you must stop it manually after disabling it:

Or, disable and stop it with one command:

This command reenables the mariadb service, which disables and then enables it. If you have created the symlinks manually for a service, this is useful for quickly resetting them to the defaults:

The following command disables the bluetooth service completely by masking it, so that it cannot be started at all:

Unmasking the bluetooth service does not enable it, so it must be started manually:

When you enable, disable, mask, or unmask a service, it remains in its current state unless you use the --now option. The --now option works with enable, disable, and mask to immediately stop or start the service, but it does not work with unmask.

See the Discussion in Recipe 4.3 to learn more about how systemd uses symlinks to manage services.

• man 1 systemctl

• The Discussion in Recipe 4.3 to learn how systemd uses symlinks to manage services

You want to know how to stop troublesome processes. A certain service may be unresponsive or running away, spawning forks and causing your system to hang. Your normal stop command is not working. What do you do?

Stopping a process is called killing the process. On Linux systems with systemd, you should use systemctl kill. On systems without systemd, use the legacy kill command.

systemctl kill is preferable because it stops all processes that belong to a service and leaves no orphan processes, nor any processes that might restart the service and continue to make trouble. First, try it with no options other than the service name, then check the status:

The service has cleanly stopped. If this does not work, then try the nuclear option:

The legacy kill command does not recognize service or command names, but rather requires the PID of the offending process:

If this does not stop it, use the nuclear option:

Use the top command to identify runaway processes. Run it with no options, and the processes using up the most CPU resources are listed at the top. Press the q key to exit top.

kill sends signals to processes, and the default signal is SIGTERM (signal terminate). SIGTERM is gentle, allowing processes to shut down cleanly. SIGTERM is also ignorable, and processes don’t have to pay attention to it. Signals can be identified by name or number; for most folks the numbers are easier to remember, so spelling out the default looks like this:

kill -9 is SIGKILL. SIGKILL stops processes immediately and uncleanly, and also attempts to stop all child processes.

Killing services with systemctl kill is easier than with kill, and more reliable. You only need the service name, and you don’t have to hunt down PIDs. It ensures that all processes belonging to the service are stopped, which kill cannot ensure.

There are a ton of signals that have accumulated over the years, and you can read all about them in man 7 signal. In my experience, the most relevant signals are SIGTERM and SIGKILL, but don’t let that stop you from learning more about the others.

If you are uncomfortable with terminology like kill, parents, children, and orphans, so am I. Maybe someday it will change.

• man 5 systemd.kill

• man 1 systemctl

• man 1 kill

• man 7 signal

You want to reboot to different system states in a manner similar to using SysV runlevels.

systemd targets are similar to SysV runlevels. These are boot profiles that start your system with different options, such as multiuser mode with a graphical desktop, multiuser mode with no graphical desktop, and emergency and rescue modes to use when your current target will not boot. (See the Discussion for more information on runlevels.)

The following command checks if the system is running and reports its state:

What is the default target?

Get the current runlevel:

Reboot to rescue mode:

Reboot to emergency mode:

Reboot to the default mode:

Reboot to a different target without changing the default:

Set a different default runlevel:

List the runlevel target files and their symlinks on your system:

List the dependencies in a runlevel target:

• man 1 systemctl

• man 8 systemd-halt.service

systemd promises faster startups, but your system starts up slowly, and you want to find out why.

You want systemd-analyze blame. Run it with no options to see a list of system processes and how long they took to start:

Analyze only user processes:

It is useful to review everything that starts at boot and perhaps find services you don’t want starting at boot. My favorite to disable is Bluetooth because I don’t use it on my servers or PCs, but many Linux distros enable it by default.