Linux – How does systemd stop services that don’t have a unit file

killlinuxrebootsignalssystemd

Systemd can inherit orphaned processes, and there are other ways a service can be running without having a unit file for the given service. I want to know what the catch-all is for services that don't have any service definition when a reboot or halt is issued.

I am specifically interested in signals sent and timeouts, i.e systemd sends all remaining services a sigterm in the order of the lexicographical-sorted service names and after 30 seconds, issues a sigkill to any remaining services. (I don't know if that's correct, but its the type of info I am interested in).

I also would love to know where this is configured and documented.

Best Answer

I took a quick look at the source code and the man pages, and I think the simple answer is:

TimeoutStopSec= Configures the time to wait for stop. If a service is asked to stop, but does not terminate in the specified time, it will be terminated forcibly via SIGTERM, and after another timeout of equal duration with SIGKILL (see KillMode= in systemd.kill(5)). Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass "0" to disable the timeout logic. Defaults to DefaultTimeoutStopSec= from the manager configuration file (see systemd-system.conf(5)).

So I look at /etc/systemd/system.conf and find:

#DefaultTimeoutStopSec=90s

So when the systemd reboot target happens systemd gets a Set of pids for children it owns. Looking at the source code, systemd/src/core/killall.c seems to show that:

static int killall(int sig, Set *pids, bool send_sighup)

takes a list of pids for all children of systemd and gets called by:

broadcast_signal(int sig, bool wait_for_exit, bool send_sighup)

Which is in the same file. So I assume any child of pid 1, will eventually get the default signal of SIGTERM, and without a unit file, the optional SIGHUP is probably never sent, it will wait the configured DefaultTimeoutStopSec and then send a SIGKILL.

Related Question