8

I've tryed to figure out how much time is given to an application to quit when receiving a SIGTERM, before it is send a SIGKILL ?

My knowledge of these signal is very low. I've read some of it in the suggested answers on Stackoverflow but I can't get a glimpse on "approximately" how much time a process can live before being SIGTERminated.

EDIT : Let's say for instance that I create a problem that purposely blocks the OS from shutting down (maybe a while(1) could do it ?)

I'm looking for answer for a process without MMI, on a standard Linux distribution, say an Ubuntu with a kernel 3.x.

My guess is that there is no waiting time. If the process disappears, the system gives it time to release its resources. Otherwise, the system kills it.

  • 3
    Is there a particular context you're asking this question in, such as signals sent to processes at shutdown? If not, then there isn't necessarily a KILL sent after a TERM. A process can receive TERM, ignore it, and keep running no problem. – cobbal Dec 19 '14 at 16:47
  • Did you tried `time` command for checking `kill` command – Arnab Nandy Dec 19 '14 at 16:56
  • @cobbal : I have trouble finding an exemple. Say my programs blocks the OS, or doesn't take care of SIGKILL signals. Is it more relevant in that context ? Sometimes, MMI can block the OS with the "Not Responding" in Windows for instance. I'm looking for a similar case, without MMI, on Linux. –  Dec 19 '14 at 17:08
  • The time between something sending a SIGTERM to a process and that same something sending a SIGKILL, assuming it even did so, would be entirely controlled by how that something was written. So you'll need to examine the script(s) that are sending the signals to find the answer. We can't guess... – twalberg Dec 19 '14 at 18:54

1 Answers1

10

Let's say for instance that I create a problem that purposely blocks the OS from shutting down (maybe a while(1) could do it ?)

Nope. It won't work. A process may not ignore some signals such as SIGKILL and SIGSTOP, except for init.
In general, you can send SIGKILL immediately after SIGTERM: there is no standard delay to let the application terminate. However, it's wise to give such application a chance to neatly close itself before the kernel will do that without further notifications.
More information here.

What concerns the system shutdown procedure is a little different. Indeed, it is the init system that decides how and when to take action; the OS helps the init daemon in this operation but indirectly (delivering signals, cleaning up resources and so on).
So, it turns out it's implementation dependent. Analyzing systemd-217, it seems to wait for 10s after sending SIGTERM.

From src/core/shutdown.c in 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 in 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 waits for SIGCHLD which would indicate the child has terminated, because most of the processes running are systemd's children.

edmz
  • 8,220
  • 2
  • 26
  • 45