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.

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.