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 cron and 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:

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

Unit files

For the majority of services, you’ll find their unit files in either:

• /etc/systemd/system/
• /lib/systemd/system

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

Troubleshooting Services

systemd and 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 /etc/systemd/.

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