systemd is a daemon manager, replacing traditional system managers such as
sysvinit. It also includes several other components designed to replace common Linux services. It’s now the default on all major distro’s, and replaces other services such as
inetd. Other Daemon managers include
upstart, which is no longer being maintained, making
systemd the most widely used daemon manager in use today.
This cheatsheet aims to provide basic usage instructions for common systemd tasks.
First, you can determine which init system you’re using by checking the process associated with PID 1, as follows:
user@debian:~$ ps -p 1 PID TTY TIME CMD 1 ? 00:00:02 systemd user@debian:~$
systemd consists of many other components:
|journald||Event logger designed to replace syslog\rsyslog. Great for checking service logs|
|logind||A login manager|
|networkd||Network manager for interfaces. Very new with minimal support|
|timedated||Time\Data manager for time zones, local time etc|
|systemd-boot||Boot manager for Linux|
systemctl is the admin tool to manage systemd. When ran with no arguments, it will list all configured units. Use
--all to list inactive ones too.
systemctl is great for quickly viewing services that may have failed.
systemd uses concept of Unit Files, a configuration file describing something to monitor. It can be of many types but mainly service & target. Systemd still works with System V init scripts, and can use existing
/etc/init.d/ scripts. Other common commands include:
systemctl status <service>- List information about service, including the location of the service configuration file, and most recent log entries
systemctl start\stop <service>- Start\stop a service
systemctl enable\disable <service>- Enable\Disable a service from startup
systemctl restart <service>- Restart a service
systemctl reload <service>- Reload the service’s configuration file (not its unit file)
systemctl daemon-reload- Reload all unit files
For the majority of services, you’ll find their unit files in either:
The unit file contains details of which binary\script needs to be called to run the service (
ExecStart), any dependencies, user requirements and many other criteria needed to start the binary.
For any given service, you can view its unit file configuration with
systemctl show <service>.
A typical service file looks like this:
# Kibana 7.10.1 service file [Unit] Description=Kibana Documentation=https://www.elastic.co/guide/en/kibana/current/index.html [Service] Type=simple User=elastic Group=elastic ExecStart=/opt/kibana-7.10.1/bin/kibana Restart=on-failure RestartSec=3 StartLimitBurst=3 StartLimitInterval=60 WorkingDirectory=/opt/kibana-7.10.1 [Install] WantedBy=multi-user.target
journald both contain tools and logs to help understand why some services might crash or fail to load:
systemctl --failed- Show all failed services
systemctl status <service>- Show if a service is loaded, or failed, as well as any recent log entries
journalctl -u <service>- List log output created by a service
Integration with System V
Debian still maintains System V init (sysvinit) scripts within
/etc/init.d, and systemd can read these and use them as services, though modern services with full systemd support should start using unit files within
Debian 9 removed the file
/etc/rc.local with the idea being that service files take over. But this is overkill so you can use the command
systemctl edit –full rc-local to create a service that basically executes whatever is in rc.local. Make sure you create the file and mark it as executable.
|Posted August 6, 2019||Tweet|
|Updated Apr 15, 2022|
|Written by John Payne|