Say, for example, that I am creating a problem that deliberately blocks the OS from shutting down (maybe time (1) can do this?)
Nope. This will not work. A process may not ignore some signals, such as SIGKILL and SIGSTOP, with the exception of init .
In general, you can send SIGKILL right after SIGTERM: there is no standard delay for the application to stop. However, it is wise to give such an application the ability to gently close itself before the kernel does so without further notice.
More details here .
Regarding the shutdown procedure, this is a little different. In fact, the init system decides how and when to take action; The OS helps the init daemon in this operation, but indirectly (signaling, clearing resources, etc.).
Thus, it turns out to be implementation dependent. Analyzing systemd-217, it seems to wait 10 seconds after sending SIGTERM.
From src / core / shutdown.c to main
log_info("Sending SIGTERM to remaining processes..."); broadcast_signal(SIGTERM, true, true); log_info("Sending SIGKILL to remaining processes..."); broadcast_signal(SIGKILL, true, false);
From src / core / killall.c to broadcast_signal
killall(sig, pids, send_sighup); [...] if (wait_for_exit) wait_for_children(pids, &mask);
Continuing in wait_for_children
until = now(CLOCK_MONOTONIC) + TIMEOUT_USEC; [...] k = sigtimedwait(mask, NULL, &ts); if (k != SIGCHLD)
where TIMEOUT_USER is #define TIMEOUT_USEC (10 * USEC_PER_SEC)
As you can see, systemd is waiting for SIGCHLD, which indicates that the child is terminated because most of the running processes are children of systemd.