In recent years, Linux distributions have increasingly transitioned from other init systems to
systemd suite of tools provides a fast and flexible init model for managing an entire machine from boot onwards.
In this guide, we’ll give you a quick run through of the most important commands you’ll want to know for managing a
systemd enabled server. These should work on any server that implements
systemd (any OS version at or above Ubuntu 15.04, Debian 8, CentOS 7, Fedora 15). Let’s get started.
The basic object that
systemd manages and acts upon is a “unit”. Units can be of many types, but the most common type is a “service” (indicated by a unit file ending in
.service). To manage services on a
systemd enabled server, our main tool is the
All of the normal init system commands have equivalent actions with the
systemctl command. We will use the
nginx.service unit to demonstrate (you’ll have to install Nginx with your package manager to get this service file).
For instance, we can start the service by typing:
- sudo systemctl start nginx.service
We can stop it again by typing:
- sudo systemctl stop nginx.service
To restart the service, we can type:
- sudo systemctl restart nginx.service
To attempt to reload the service without interrupting normal functionality, we can type:
- sudo systemctl reload nginx.service
By default, most
systemd unit files are not started automatically at boot. To configure this functionality, you need to “enable” to unit. This hooks it up to a certain boot “target”, causing it to be triggered when that target is started.
To enable a service to start automatically at boot, type:
- sudo systemctl enable nginx.service
If you wish to disable the service again, type:
- sudo systemctl disable nginx.service
There is a great deal of information that we can pull from a
systemd server to get an overview of the system state.
For instance, to get all of the unit files that
systemd has listed as “active”, type (you can actually leave off the
list-units as this is the default
- systemctl list-units
To list all of the units that
systemd has loaded or attempted to load into memory, including those that are not currently active, add the
- systemctl list-units --all
To list all of the units installed on the system, including those that
systemd has not tried to load into memory, type:
- systemctl list-unit-files
systemd component called
journald collects and manages journal entries from all parts of the system. This is basically log information from applications and the kernel.
To see all log entries, starting at the oldest entry, type:
By default, this will show you entries from the current and previous boots if
journald is configured to save previous boot records. Some distributions enable this by default, while others do not (to enable this, either edit the
/etc/systemd/journald.conf file and set the
Storage= option to “persistent”, or create the persistent directory by typing
sudo mkdir -p /var/log/journal).
If you only wish to see the journal entries from the current boot, add the
- journalctl -b
To see only kernel messages, such as those that are typically represented by
dmesg, you can use the
- journalctl -k
Again, you can limit this only to the current boot by appending the
- journalctl -k -b
While the above commands gave you access to the general system state, you can also get information about the state of individual units.
To see an overview of the current state of a unit, you can use the
status option with the
systemctl command. This will show you whether the unit is active, information about the process, and the latest journal entries:
- systemctl status nginx.service
To see all of the journal entries for the unit in question, give the
-u option with the unit name to the
- journalctl -u nginx.service
As always, you can limit the entries to the current boot by adding the
- journalctl -b -u nginx.service
By now, you know how to modify a unit’s state by starting or stopping it, and you know how to view state and journal information to get an idea of what is happening with the process. However, we haven’t seen yet how to inspect other aspects of units and unit files.
A unit file contains the parameters that
systemd uses to manage and run a unit. To see the full contents of a unit file, type:
- systemctl cat nginx.service
To see the dependency tree of a unit (which units
systemd will attempt to activate when starting the unit), type:
- systemctl list-dependencies nginx.service
This will show the dependent units, with
target units recursively expanded. To expand all dependent units recursively, pass the
- systemctl list-dependencies --all nginx.service
Finally, to see the low-level details of the unit’s settings on the system, you can use the
- systemctl show nginx.service
This will give you the value of each parameter being managed by
If you need to make a modification to a unit file,
systemd allows you to make changes from the
systemctl command itself so that you don’t have to go to the actual disk location.
To add a unit file snippet, which can be used to append or override settings in the default unit file, simply call the
edit option on the unit:
- sudo systemctl edit nginx.service
If you prefer to modify the entire content of the unit file instead of creating a snippet, pass the
- sudo systemctl edit --full nginx.service
After modifying a unit file, you should reload the
systemd process itself to pick up your changes:
- sudo systemctl daemon-reload
Another function of an init system is to transition the server itself between different states. Traditional init systems typically refer to these as “runlevels”, allowing the system to only be in one runlevel at any one time.
systemd, “targets” are used instead. Targets are basically synchronization points that the server can used to bring the server into a specific state. Service and other unit files can be tied to a target and multiple targets can be active at the same time.
To see all of the targets available on your system, type:
- systemctl list-unit-files --type=target
To view the default target that
systemd tries to reach at boot (which in turn starts all of the unit files that make up the dependency tree of that target), type:
- systemctl get-default
You can change the default target that will be used at boot by using the
- sudo systemctl set-default multi-user.target
To see what units are tied to a target, you can type:
- systemctl list-dependencies multi-user.target
You can modify the system state to transition between targets with the
isolate option. This will stop any units that are not tied to the specified target. Be sure that the target you are isolating does not stop any essential services:
- sudo systemctl isolate multi-user.target
For some of the major states that a system can transition to, shortcuts are available. For instance, to power off your server, you can type:
- sudo systemctl poweroff
If you wish to reboot the system instead, that can be accomplished by typing:
- sudo systemctl reboot
You can boot into rescue mode by typing:
- sudo systemctl rescue
Note that most operating systems include traditional aliases to these operations so that you can simply type
sudo poweroff or
sudo reboot without the
systemctl. However, this is not guaranteed to be set up on all systems.
By now, you should know the basics of how to manage a server that uses
systemd. However, there is much more to learn as your needs expand. Below are links to guides with more in-depth information about some of the components we discussed in this guide:
By learning how to leverage your init system’s strengths, you can control the state of your machines and more easily manage your services and processes.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.