Systemctl Command on Linux (Systemd Manager) [Basic Guide]

The systemctl command in Linux is the Systemd manager, which is considered the “almost everything” manager in Linux.

The systemd system is already widely used in the most popular distributions, especially in Kernel versions greater than 2.6. You will hardly find a modern distribution that doesn’t use systemd.

Its main advantage is that it loads the system more quickly, running services and processes in parallel. This was possible with the arrival of the new processors equipped with multiple cores, which allow the execution of several threads in parallel.

Systemd’s new features include:

• Activation via socket and bus (executes services on demand);
• Better parallelization of processes;
• Use of cgroups (control groups) instead of PIDS;
• Supports the creation of memory state images to save and restore execution states.

The group control system allows systemd to supervise processes in order to ensure that, when a service is stopped, all child processes, grandchildren, great-grandchildren, etc. are also stopped.

With more robust management, more CPU cycles are needed to create new processes. But due to the high performance of the processors, this doesn’t seem to be a problem for systemd.

In systemd, process loading, runlevel changes, and load scripts are quite different from init.

To begin with, Systemd treats Runlevens as Targets or targets. Each Target can have multiple Units.

Understand Units as objects that are read by Systemd. These objects are configuration files that define, for example:

• Object name
• Prerequisites for execution (if they depend on other Units)
• What should be done, for example, running a particular program or service
• What should be done after the command is started.

These files are very comprehensive and can define a number of things depending on their type. The most common Systemd Units are:

• Service type: used to manage a service or application on the server. This will include how to start or stop the service, under what circumstances it should start automatically, and the dependency and order information for the related software. They are files with the extension .service.
• Mount type: This unit defines a mount point in the system to be managed by systemd. They are files with the extension.

• Time type (timer): defines that something will be managed by systemd, similar to a Cron job, for delayed or scheduled activation. They are files with the extension .timer

See a comparison table of Runlevel (System V) and Systemd Targets:

TABLE – Linux Runlevels

Runlevel	Description	Target
0	zero defines an elegant and quick shutdown of the system.	poweroff.target
1	System Maintenance	rescue.target
2	Multi-user pattern multi-user text mode.target	multi-user.target
3	pattern multi-user text mode	multi-user.target
4	Standard multi-user mode	multi-user.target
5	Multi-user pattern	graphical.target
6	Reboot of the machine	reboot.target

The syntax of Systemd configuration files, called units, is inspired by the Windows .ini files. These files are found in two directories, namely:

/usr/lib/systemd/system/: Units from installed software packages;

/etc/systemd/system/: Units installed by the administrator;

Emergency and Rescue Mode

Two extra special targets are rescue and emergency.

Rescue.target

The rescue or recovery mode can be used for more “lightweight” system maintenance. In this mode the system:

• Mount all local file systems;
• Only the root user is allowed to log in to the system;
• Network services are disabled and only a few other services are started;
• The systemctl is-system-running command will return maintenance status.

In this mode it is possible to run disk utilities such as fsck or xfs_repair to fix corrupted disks. This mode is also useful for correcting faults in system or service configurations.

Emergency.target

The Emergency target is for heavy maintenance when a lot goes wrong, usually with corrupted data. In this mode the system:

• Mounts only the root file system as read-only;
• Similar to recovery mode, it only allows the root user to log in to the system;
• network services are disabled and only a few other services are started;
• the systemctl is-system-running command will return the maintenance status.

If the system goes into emergency mode without a doubt, there are serious problems. This mode is used for situations where even the rescue mode doesn’t work.

Systemctl command

$ systemctl [options] command [name]

The systemctl command controls the systemd service management system show. Possible commands are:

Action	Command
list-sockets	Lists units of the socket type
list-timers	List the units of the type timer
start NAME	Start the unit NAME
stop NAME	For one or more units entered in NAME
reload NAME	Reload the unit NAME
restart NAME	RESTART one or more units entered in NAME
try-restart NAME	Restart the units if they are running. Do nothing if they are not running
isolate NAME	Start all specified units and their dependencies, and for all others. Used to change target
status [NAME]	Shows the status of one unit or all if nothing is specified
show [NAME]	Shows the properties of one or more units
cat NAME	Shows the unit files content
enable NAME	Enables a unit to load during boot. Do not start a unit
disable NAME	Disables a unit to load during boot. Do not stop the unit
daemon-reload	Restart the systemd service.
mask NAME	Set the limbo unit, making it impossible to execute it.
unmask NAME	Returns the unit from limbo, allowing it to be started.

Generally, the developer does not need to know how to create, edit, or modify any unit. You just need to know how to list the units, start, stop, enable, disable, view the status, and change Runlevel.

You may or may not specify the length of the units (.target/.service/.timer) when passing the command. Systemctl will always search for a pattern indicated in the NAME.

Status in Systemctl

Thus, to verify the cron service (scheduler) you can use the status command followed by the name of the cron unit with or without the extension ”.service“:

# systemctl status cron

Or

# systemctl status cron.service
cron.service - Command Scheduler
Loaded: loaded (/lib/systemd/system/cron.service; enabled)
Active: active (running) since Mon, 28 May 2012 6:09:57 PM
Main PID: 673 (cron)
CGroup: name=systemd: /system/cron.service
+ 673 /usr/sbin/cron -n

Stop a service with systemctl

To stop a service:

# systemctl stop cron.service

See the service status when stopped:

# systemctl status cron.service
cron.service - Command Scheduler
Loaded: loaded (/lib/systemd/system/cron.service; enabled)
Active: inactive (dead) since Mon, May 28, 2012 6:18:26 PM
Main PID: 673 (code=exited, status=0/success)
CGroup: name=systemd: /system/cron.service

Start a service with systemctl

To start a service:

# systemctl start cron.service

Restart a service with systemctl

To restart a service:

# systemctl restart cron.service

Enable a service at boot with systemctl

To enable a service during system load, use the enable command:

# systemctl enable cron.service

Disable a service with systemctl

To disable a service during system load, use the disable command:

# systemctl disable cron.service

Change the runlevel with systemctl

To change the runlevel to text mode (runlevel 3), use the isolate command

# systemctl isolate multi-user.target

To change the runlevel to graphic mode (runlevel 5):

# systemctl isolate graphical.target

To see which runlevel is running, you can use the get-default command:

$ systemctl get-default
Graphical.target

Change the default runlevel with systemctl

There are two ways to change the default runlevel:

The first is to delete and recreate the symbolic link manually:

a) To delete the symbolic link:

# rm /etc/systemd/system/default.target

b) To set runlevel3 as default, recreate the symbolic link:

# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

The second way is to use systemctl to do this for you, with the set-default command:

# systemctl set-default multi-user.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target. 

To see which units a given service is dependent on, you can use the list-dependencies command:

$ systemctl list-dependencies apache2 
apache2.service 
? ? ?-.mount 
? ? ?system.slice 
? ?sysinit.target 
? ? ?apparmor.service 
? ? ?dev-hugepages.mount 
? ? ?dev-mqueue.mount 
? ? ?keyboard-setup.service 
? 496 kmod-static-nodes.service

(…)

It is important to say that when a particular service is started by systemd, the manager will also start all the dependencies that that particular service requires.

For example, if the system.slice service is stopped and disabled, and the administrator starts the apache2 service, the system.slice service will start, so that the apache2 service works correctly.

Mask a service with systemctl

To prevent a service from running, even if it is disabled and is part of a unit dependency, the mask command can be used:

# systemctl mask apache2 
Created symlink /etc/systemd/system/apache2.service ? /dev/null. 

In this way, systemctl will create a symbolic link from the service to limbo /dev/null. Thus, the service will not start in any way, even if it is dependent on another unit:

# systemctl start apache2 
Failed to start apache2.service: Unit apache2.service is masked. 

To return the service, the unmask command can be executed, returning the exile unit:

# systemctl unmask apache2 
Removed /etc/systemd/system/apache2.service. 

Restart systemd with systemctl

Every time a unit is created or changed, it is necessary to restart the Systemd service with the daemon-reload command:

# systemctl daemon-reload

Systemd maintains certain compatibility with System V through a script that mimics the service command, which actually executes systemctl commands.

Disabling Unnecessary Services

An important administrator task is to disable unnecessary services, especially network services.

The first step is to check which services are running with the command:

$ systemctl status

This command displays a list of all services running.

You can also list open ports and their respective processes with the netstat or ss commands:

# netstat -tunlp

Or

# ss -tunlp

To turn off unnecessary services, use the command:

# systemctl stop servicename

And to disable in the system loading process:

# systemctl disable servicename

If the distribution still uses System V Init Daemon, the running services can be viewed with the command:

$ service --status-all

Or with the command:

$ chkconfig --list

To stop the services, the command can be used:

# service servername stop

And to disable:

# chkconfig servicename off