SYSTEMD.KILL(5)

💅 SYSTEMD.KILL — like, the whole "how do we actually make these processes go away" situation

okay bestie, pull up a chair 🫶 this is systemd.kill, manual section 5, and it's literally the group chat rules for how systemd ends processes. no cap.

---

✨ SYNOPSIS ✨

service.service, socket.socket, mount.mount, swap.swap, scope.scope

---

🌸 DESCRIPTION 🌸

so here's the tea ☕: unit config files for services, sockets, mount points, swap devices and scopes all share a little subset of config options. and that subset? it defines the killing procedure — the whole "how do we yeet the processes that belong to this unit" plan. 💀

this page lists the options that all five of those unit types share. if you want the common options that every unit config file gets, go read systemd.unit(5). and if you want the options that are specific to one unit type, the girlies are here:

• systemd.service(5)
• systemd.socket(5)
• systemd.swap(5)
• systemd.mount(5)
• systemd.scope(5)

where do you actually put these kill options? depends on your unit type, bestie:

• [Service]
• [Socket]
• [Mount]
• [Swap]

that's it, that's the section. pick the one that matches your unit. 🎀

---

👑 OPTIONS 👑

KillMode=

specifies how the processes of this unit shall be killed. one of: control-group, mixed, process, none. pick your fighter 💅

• if it's set to control-group, all remaining processes in the control group of this unit get killed on unit stop. (for services specifically: this happens after the stop command is executed, as configured with ExecStop=.) slay.
• if it's set to mixed, the SIGTERM signal (see below 👇) goes to the main process, while the subsequent SIGKILL signal (also see below) goes to all remaining processes of the unit's control group. spicy hybrid energy.
• if it's set to process, only the main process itself is killed. (not recommended! 🙈)
• if it's set to none, no process is killed at all (strongly recommended against! 😭). in that case, only the stop command gets executed on unit stop, but no process will be killed otherwise. processes that are still alive after stop just… stay chillin' in their control group, and the control group keeps existing after stop unless it's empty.

ok real talk: it is not recommended to set KillMode= to process or even none, because that literally lets processes escape the service manager's lifecycle and resource management, and they can keep running even while their service is considered stopped and is assumed to not consume any resources. the audacity?? 🙄

here's the order of operations, bestie. processes will first be terminated via SIGTERM (unless the signal to send is changed via KillSignal= or RestartKillSignal=). optionally, this is immediately followed by a SIGHUP (if enabled with SendSIGHUP=). and if processes still remain after:

• the main process of a unit has exited (this one applies to KillMode=: mixed)
• the delay configured via the TimeoutStopSec= has passed (this one applies to KillMode=: control-group, mixed, process)

…then the termination request gets repeated with the SIGKILL signal, or the signal specified via FinalKillSignal= (unless that's disabled via the SendSIGKILL= option). see kill(2) for more info, iykyk.

defaults to control-group. 🌈

added in version 187.

KillSignal=

specifies which signal to use when stopping a service. this controls the signal that gets sent as the first step of shutting down a unit (see above ⬆️), and it's usually followed by SIGKILL (see above and below, we love a callback). for a list of valid signals, check signal(7). defaults to SIGTERM. ✨

little detail that matters: right after sending the signal specified in this setting, systemd will always send SIGCONT, to make sure that even suspended tasks can be terminated cleanly. not me making sure the paused girlies get their moment 💅

added in version 187.

RestartKillSignal=

specifies which signal to use when restarting a service. it's the same as KillSignal= described above, with one exception: this setting is used in a restart job. not set by default, and the value of KillSignal= is used instead. 🔁

added in version 244.

SendSIGHUP=

specifies whether to send SIGHUP to remaining processes immediately after sending the signal configured with KillSignal=. this is useful to indicate to shells and shell-like programs that their connection has been severed. takes a boolean value. defaults to "no". 🦋

added in version 207.

SendSIGKILL=

specifies whether to send SIGKILL (or the signal specified by FinalKillSignal=) to remaining processes after a timeout, if the normal shutdown procedure left processes of the service around. when this is disabled, a KillMode= of control-group or mixed service will not restart if processes from prior services exist within the control group. takes a boolean value. defaults to "yes". 🔥

added in version 187.

FinalKillSignal=

specifies which signal to send to remaining processes after a timeout if SendSIGKILL= is enabled. the signal you configure here should be one that is not typically caught and processed by services — SIGTERM is not suitable, bestie, it's too polite for this job. developers can find it useful to use this to generate a coredump, so they can troubleshoot why a service did not terminate upon receiving the initial SIGTERM signal. you can achieve that by configuring LimitCORE= and setting FinalKillSignal= to either SIGQUIT or SIGABRT. defaults to SIGKILL. 💀

added in version 240.

WatchdogSignal=

specifies which signal to use to terminate the service when the watchdog timeout expires (enabled through WatchdogSec=). defaults to SIGABRT. 🐕

added in version 240.

---

🫶 SEE ALSO 🫶

systemd(1), systemctl(1), journalctl(1), systemd.unit(5), systemd.service(5), systemd.socket(5), systemd.swap(5), systemd.mount(5), systemd.exec(5), systemd.directives(7), kill(2), signal(7)

---

and that's the whole page, bestie, you ate it 🍓 this was systemd 262.1, SYSTEMD.KILL(5) — go forth and terminate your processes with main character energy 👑✨💜