How to Manage Systemd Services and Units on ECS with the Systemctl Command

What Can You Manage with systemctl?

Most of the actions you perform with this command, revolve around units, which can be of various types, like service, socket, target, timer, and others (you will learn what these are, later in this article). Here’s a short list of what you will usually use systemctl for:

  • Manage units (start, stop, restart, enable, disable, etc.)
  • Analyze running units, see which ones work, which failed, check their status in various ways.
  • Edit unit files that control the lifecycle of a process (services), or when an action will take place (timers), how a filesystem should be mounted (mount units), etc.
  • Reboot and poweroff the system. You can also sleep/standby or hibernate, but not on servers; this only applies to home computers.
  • Switch to a different target (previously called runlevel), or change the default target the system boots into. This is very rarely used on servers, though, because the multi-user.target is almost always the only one you need as the active/default boot target.

Example of the Anatomy of a systemd Unit File

If you host your website with Nginx, you will have an nginx.service file. This will be pulled in by your package manager when you install the utility. In this file, there are instructions for systemd, telling it how to start the nginx daemon process (ExecStart), what commands to execute to stop it (ExecStop), to reload its configuration (ExecReload), and so on. Here's how nginx.service looks like on Ubuntu 18.04:

# /lib/systemd/system/nginx.service
# Stop dance for nginx
# =======================
#
# ExecStop sends SIGSTOP (graceful stop) to the nginx process.
# If, after 5s (--retry QUIT/5) nginx is still running, systemd takes control
# and sends SIGTERM (fast shutdown) to the main process.
# After another 5s (TimeoutStopSec=5), and if nginx is alive, systemd sends
# SIGKILL to all the remaining processes in the process group (KillMode=mixed).
#
# nginx signals reference doc:
# http://nginx.org/en/docs/control.html
#
[Unit]
Description=A high performance web server and a reverse proxy server
Documentation=man:nginx(8)
After=network.target
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/n
TimeoutStopSec=5
KillMode=mixed
[Install]
WantedBy=multi-user.target
systemctl --version

systemd Unit Types

In the commands offered as examples, you will see actions performed on services, which are just one type of unit. Although you will work with services most often, you may also need to touch other types of units, such as timers or sockets. The commands are similar though. For example, if you start a service with systemctl start unit.service, you start a timer with systemctl start unit.timer. Basically, the only thing that changes is the name of the unit.

ssh.service
ssh@.service
ssh.socket
ls /lib/systemd/system
  • Service — Usually manages the lifecycle of a daemon, like the SSH server, a web server like nginx or Apache, cron daemon, etc. But it is not limited to daemon/server utilities. These units can manage any kind of program/process, according to the instructions contained in the file. When does it start, what happens when it crashes, how it should restart, what should happen when it stops, are just a few of the things a service unit can control.
  • Target — Contains a list of units, needed to achieve a certain system state. For example, multi-user.target is a common unit of this type. This groups together all the units that should be started to launch a multi-user environment, which is a fancy way of describing an operating system that multiple users can connect to and utilize it at the same time. If you run systemctl list-dependencies, you can easily see how such targets work (press "q" when you want to quit, if you launched that command).
  • Socket — With this, systemd can start a service only when there is a demand for it. For example, a visitor tries to connect to your server’s IP address, on port 1234. The daemon that should listen on that port is not currently running, maybe to save resources. However, systemd will listen for incoming connections on this port. As soon as it gets a request, it looks for the instructions in the corresponding .socket file, to start a particular service. This, in turn, launches the daemon that should listen on that port, and the request gets passed from systemd to the daemon (what info systemd received on its socket, it will pass to the daemon after it starts). Besides saving resources, this can also speed up the boot process, as services that are required later won't be unnecessarily launched at boot time. Furthermore, it helps the machine avoid having to load programs that are rarely used. This means that some daemons/utilities may run just once every few days, and only run for a few minutes (e.g., a remote backup request may trigger this, only when necessary). Besides network sockets, these unit types can also make use of IPC sockets or FIFO files, which means that even a program that needs another program can just send a request on a local (IPC) socket and start up the utility it requires.
  • Timer — This does a similar job to cron. Simply put, an active timer unit contains information about what to do/run at a specific future time. Normally, these are periodic jobs that need to run at a specific time, daily, on particular days, weekly, or monthly, etc. Timers are not limited to specific times though. Instead of running a service every day at 12AM, you can set it to run one hour after the machine boots, for example. So, instead of having a fixed date and/or time, they have a relative trigger time that depends on another event.
man systemd.service
man systemd.timer

How to List Units Managed by systemd

It’s useful to maximize your terminal window before you continue. Some output is very wide and won’t fit properly, or get misaligned if your SSH client window is not wide enough. Run this command:

systemctl list-units
systemd-journal-flush.service                                               loaded active exited    Flush Journal to Persistent Storage
ssh.service                                                                 loaded active running   OpenBSD Secure Shell server

How to Filter Units Listed by systemctl

To also list units that are inactive, run

systemctl list-units --all
systemctl --type timer list-units
  • service
  • socket
  • timer
  • mount
  • automount
  • path
  • scope
  • slice
  • target
  • device
  • swap

How to Check Status of Units with systemctl

You can also list units, organized in a dependency tree:

systemctl list-dependencies
systemctl status ssh.service
Loaded: masked (/dev/null; bad)
Process: 673 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
systemctl list-unit-files

How to Manage Units with systemctl

systemctl disable nginx.service
systemctl enable nginx.service

Make Sure a Unit Can Never Start (Mask Unit)

Sometimes though, even if you stop a unit and disable it from starting at boot, you will notice that the unit may start “by itself,” later on. This happens in the case of units that are configured in such a way, that they may be launched by other units or utilities in case of necessity (e.g., socket-based activation). To make sure that the unit cannot be started under any circumstances, you can force-disable it with

systemctl mask nginx.service
systemctl unmask nginx.service
Failed to mask unit: File /etc/systemd/system/nginx.service already exists.
mv /etc/systemd/system/nginx.service /root

Manage Unit Running State with systemctl

To start a unit:

systemctl start nginx.service
systemctl stop nginx.service
systemctl kill -s SIGKILL nameof.service
systemctl restart nginx.service
systemctl reload nginx.service

How to View and Edit Units with systemctl

You can display the contents of a unit file with systemctl cat, for example:

systemctl cat ssh.service
systemctl edit --full ssh.service
systemctl revert ssh.service

How to Reboot, Shutdown, Standby and Hibernate with systemctl

On servers, you will normally only use the first two operations:

systemctl reboot
systemctl poweroff
systemctl suspend
systemctl hibernate
systemctl hybrid-sleep

Conclusion

These are the scenarios for which systemctl is most commonly used for. You can also read the systemctl manual, online, which often gets updated with new information after the utility receives new features.

Original Source

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alibaba Cloud

Alibaba Cloud

Follow me to keep abreast with the latest technology news, industry insights, and developer trends. Alibaba Cloud website:https://www.alibabacloud.com