Managing processes with systemd
Supervisor
Sometimes you need to stop or restart individual services after a boot or reboot. Systemctl
and the stop
, start
, restart
, and reload
commands can help; for example:
systemctl stop mysqld systemctl start mysqld
A user who wants to start or stop the system service must authenticate. If the process does not respond to the stop
command, the only way out is:
systemctl kill unit_name
This command sends a kill signal to each process in the process group, even to those that the parent process forked at a later stage. The effect thus resembles killall process name
. The -s
option also lets you send another specific signal to a process; for example, SIGHUP
to trigger a reload as shown in the following example:
systemctl kill -s HUP --kill-who=main crond.service
The --kill -who
option ensures that only the main
process receives the signal.
Alternatively, you could also type --kill-who=control
to cover all control processes; for example, all processes called by the = ExecStartPre=
, ExecStop=
, or ExecReload=
options in the unit file. However, --kill-who=all
(and this is the default) would affect the control and main processes.
If you do not simply want to stop a service, but you also want to prevent it from restarting on the next boot, disable it with the following command:
systemctl disable Unit_name
If the process is still running, it is not stopped by disabling; if it was already stopped, it can still be started manually even after disabling. Only automatic restarting at the next boot time is prevented.
There is an even more precise use case, even if it is rarely necessary: After typing:
systemctl mask Unit_name
the service will not start automatically (as is the case with disable
), and it also won't start manually. This command links the unit file to /dev/null
; if you want to undo this action, you need to delete the link.
Analysis of Time Requirements
If you have ever considered where your computer is wasting time at bootup, and maybe used a tool like Bootchart to optimize the boot process, you will find life much easier with systemd. Systemd already has the necessary analysis tools built in. The following command:
systemd-analyze blame
produces a list in descending order of all started services with the time they needed for initialization (Listing 4). Note, however, that the times listed may have run in parallel, since the boot process is no longer strictly serial. The tool does not reveal anything about the causes for long execution times, but system administrators can at least consider whether they really need these time wasters.
Listing 4
Analysis (excerpt)
The whole picture becomes even clearer if you visualize the data. The following command:
systemd-analyze plot > plot.svg eog plot.svg
draws a graph with the service startup information.
Conclusions
Systemd lets you define how to start a service and what the service can do at runtime. The clear and simple syntax is in contrast to the shell-script-based methods used in earlier init versions, and systemd offers some interesting new options for security, analysis, and data visualization.
« Previous 1 2
Buy this article as PDF
(incl. VAT)