Killing systemd service with and without systemctl

Gordon asked:

What is the difference between killing an running daemon systemd service like this :

kill -SIGKILL 3645


systemctl -s kill -SIGKILL 3645

where 3645 is the pid of the systemd service.Also are there any drawbacks of using the first method?

My answer:

First, your systemctl syntax is wrong: systemctl kill expects a unit name, not a PID, and -s requires a signal name. As written, it won’t do anything but give you an error message:

Failed to parse signal string kill.

If you fix that, it will then tell you:

Failed to kill unit 3645.service: Unit 3645.service not loaded.

The correct syntax would be:

systemctl kill -s SIGWHATEVER whatever.service

The difference, obviously, is that you can send signals to processes based on the systemd unit, rather than pid. Because a unit might run multiple processes, systemd can then send the same signal to all processes running under the unit, and indeed, this is the default. The --kill-who= option lets you change this if necessary.

Generally, though, it’s not a good idea to get into the habit of sending SIGKILL to anything. You should stop your services normally whenever possible, e.g. with systemctl stop whatever.service. SIGKILL is the same as the potentially destructive kill -9 you have probably heard of and been warned about. And, if you kill a service via either method and it is configured to restart automatically, it may do so. This may or may not be what you want, depending on why you are trying to send a kill signal.

View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.