Using basic systemd commands

Control Plan

Article from Issue 182/2016

Systemd is a complex management structure with many commands and capabilities. We provide an overview of a few basic commands and their use.

One of the criticisms of systemd, the new system management framework [1], is that it is a monolithic structure that violates the time-honored Unix principle of using small, dedicated tools. However, when you examine it, systemd proves less monolithic than it sounds. Instead, it has introduced a series of new tools for system administration, each of which has its own specific purpose.

What gives systemd a monolithic appearance is that its structure is consistent throughout. Users can be confident that a file ending in "ctl" is a command, whereas one ending in "conf" is a configuration file. Even more importantly, each command has the same structure:


Often, options and sub-commands are the same for different commands.

Systemd tends to thoroughness, so it is impractical to list all of the main options and commands here. Instead, there is room only for some basic functions to give a sense of what each command can do. For more detailed information, consult each command's man page or the systemd documentation [2]. You can get a sense of the complexity of systemd from the fact that systemctl, the most important systemd command, has a man page of 868 lines – more than four times as long as a command such as cp or ls. In this article, I'll describe some of the basic commands introduced by systemd.


Systemctl is systemd's main command. It manages units, which are the files to manage system resources. Units are organized into control groups, such as service, socket, device, mount, automount, and snapshot, which stores an image of the current state of systemd for later restoration. These control groups are used as an extension for unit files, so you always know which control group a unit belongs to. A system can have between 150 and 300 units, depending on its setup and what it runs. Usually, systems that run Gnome technologies have more units than KDE, possibly because systemd was initially developed with Gnome in mind.

The systemctl command manages units – enabling and disabling them, changing their state, and managing positive dependencies (what must be present for a unit to operate) and reverse dependencies (what cannot be present for a unit to operate). This broad array of controls makes systemctl extremely powerful – and, therefore, potentially capable of crashing your machine if used carelessly.

You can use --all (-a) to see a list of units as you compose the command structure (Figure 1). To avoid unintended consequences, whenever possible, add the option --type= (-t), to limit the command to particular control groups such as sockets or service, --state=, to specify whether units whose state is LOAD, SUB, or ACTIVE are affected, or both options. Use the command list-dependencies to view a unit's dependencies, and the --reverse option to list a unit's reverse dependencies.

Figure 1: Systemctl manages system resources, called units. Here, all socket units are listed.

Most of systemctl's basic functions are in its commands. With show and status, you can read current information about a unit or a comma-separated list of units. The start and stop commands activate a unit, whereas


edits a unit's definition.


Journals are one the more controversial features of systemd, because they are binary files rather than the traditional text files generally used in Linux. However, in compensation, the journalctl command has a thorough selection of choices for viewing logs.

Many distributions do not ship with systemd's journal enabled, so check to see if your installation has a /var/log/journal file. If not, you can set it up with the command:

setfacl -R -nm g:adm:rx,d:g:adm:rx /var/log/journal

You should also edit /etc/systemd/journald.conf, using the settings storage=persistent to save the journal permanently and SystemMaxFileSize = 100M so that the journal does not grow too large.

The bare command displays the journal, oldest entry first (Figure 2). However, for convenience, consider adding the option --output=verbose so that information is not cut off and --reverse (-r) so that the oldest entry is first.

Figure 2: Systemd's journal begins by default with the oldest entry at the top of the list.

You can filter journal messages with --dmesg (-k) to view only messages from the kernel, with --system for messages from system services, or with --PID= to view messages from a particular service. If you want to view messages from a particular book, run journalctl with --system-boots, then use the identifier in the second field of the output to run the records for the boot you want to examine. Alternatively, you can use line=NUMBER to view only a set number of events or use --since or --until to set a range of dates or times.

Halt, Poweroff, Reboot, Shutdown

These commands all close down the system. Technically, halt closes down the system without turning the power off, whereas poweroff and shutdown do turn the power off, and reboot does a cold reboot. However, all four commands include the options --poweroff and --reboot, so any distinction is blurred.

The shutdown command is unique in that options may be followed by a time to activate the command. The time is in hh:mm format, using a 24-hour clock. You also have the option of specifying a time in the future by specifying a number of minutes with a plus sign as a prefix. If no time is specified, then the default is +1. Using +0 runs the command immediately. At the end of a shutdown command with a time argument, you can use the wall command to broadcast a message to all users.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Command Line: Systemd

    Wondering what all the fuss is about systemd? We explain the basic concepts and capabilities of the new system management suite – coming soon to a distro near you.

  • Systemd GUIs

    Graphical frontends make it easier to take full advantage of the Systemd process manager. We examine some leading tools for the KDE environment.

  • Systemd Graphical Tools

    Systemd has won the race, as indicated by the several tools that already offer a service just a mouse click away. We look at six of these tools.

  • Professor Knopper's Lab – Removing systemd

    The systemd service manager has been widely adopted by many Linux distros, so why would you want to remove it? The professor reveals why and how.

  • Working the System

    Every major aspect of a system that runs in userland can be controlled by systemctl, a command that acts on systemd's units.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More