Why Bash Ignores SIGTERM – Understanding Signal Handling

bashsignals

Sometimes when I want to logout quickly I do kill -15 -1. I've noticed that bash is ignoring SIGTERM.

I wonder what's the rationale for such bash behavior?

It's not very UNIX'y to ignore SIGTERM without a good reason, isn't it?

UPDATE:

same (no)effect for all:

$ kill -TERM $$
$ type kill
kill is a shell builtin
$ command kill -TERM $$
$ /bin/kill -TERM $$

UPDATE2:

From man bash:

When bash is interactive, in the absence of any traps, it ignores
SIGTERM

So it's done on purpose. But why?

Best Answer

First, this isn't specific to bash. ATT ksh, dash and zsh behave the same way: they ignore SIGTERM and SIGQUIT during command line edition; as for mksh, it also doesn't quit but treats them like SIGINT.

Both the ksh manual and the bash manual justify ignoring SIGTERM in these terms:

so that kill 0 does not kill an interactive shell

kill 0 kills all processes in the process group that the shell is in¹. In a nutshell, the process group consists of all the processes running in the foreground on a terminal, or all the processes in a background or suspended job.

More precisely, this is what happens in modern shells with job control. In such shells, kill 0 wouldn't be useful, as the shell would be in a process group of its own. Older shells (or modern shells after set +m) did not create process groups for background commands. So you could use the command kill 0 to kill all background commands without getting logged out.² Thus the kill 0 rationale looks like an old one which is no longer justified nowadays but kept for backward compatibility.

However there are other similar situations where making the shell immune is useful. Consider the case where you have processes hogging a terminal and you want to kill them without getting logged out. Many systems have a tool like pkill which let you kill the processes running on a terminal. You can run pkill -t $TTY or pkill -QUIT -t $TTY to kill all processes that are running on the current terminal, except the shell which ignores the signal.

A shell normally goes away either when the user exits it (with a command like exit or logout), or when its terminal signals the end of the input (the user can cause this by pressing Ctrl+D) or goes away altogether. In this last case, the shell receives the signal SIGHUP, and it doesn't ignore that one.

For your use case of logging out of an X session, kill -15 -1 will do it, since it kills the terminal emulator which causes the shell to receive SIGHUP. It's in fact enough to kill the X server, but that requires finding its process ID. If you want the same command to work on a text session, you can use kill -15 -1; exit. That's quite a dangerous command to have at your fingertips anyway.

¹ _{This doesn't seem to be mentioned in shell manuals as a rule; it's a feature of the underlying system call. It is mentioned explicitly in the POSIX specification.}
² _{Nowadays, to do that, run jobs -l to see a list of jobs with their process group ID, then kill -123 -456 … to kill the process groups.}

Related Solutions

Bash – How to Forward SIGTERM to Child in Bash

Try:

#!/bin/bash 

_term() { 
  echo "Caught SIGTERM signal!" 
  kill -TERM "$child" 2>/dev/null
}

trap _term SIGTERM

echo "Doing some initial work...";
/bin/start/main/server --nodaemon &

child=$! 
wait "$child"

Normally, bash will ignore any signals while a child process is executing. Starting the server with & will background it into the shell's job control system, with $! holding the server's PID (to be used with wait and kill). Calling wait will then wait for the job with the specified PID (the server) to finish, or for any signals to be fired.

When the shell receives SIGTERM (or the server exits independently), the wait call will return (exiting with the server's exit code, or with the signal number + 128 in case a signal was received). Afterward, if the shell received SIGTERM, it will call the _term function specified as the SIGTERM trap handler before exiting (in which we do any cleanup and manually propagate the signal to the server process using kill).

Bash – Why does Bash ignore SIGINT if its currently running child handles it

The problem is well explained here, as WCE wait and cooperative exit and I encourage you to read it. Basically, your signal is received by all foreground processes, ie the shell and the program, sleep or aplay. The program exits with return code 130 if it does not handle the signal. The shell does a wait for the child to end, and sees this, and the fact that it got the signal too, so exits.

When the program captures the signal, it often just exits with code 1 (as with aplay). When the shell waits for the child, it sees that it did not end due to the signal and so has to assume the signal was a normal aspect of the program's working, so the shell carries on as normal.

For your example, the best way to handle aplay is to check its return code for non-zero and stop:

(while aplay test.wav; do :; done)

The above-mentioned article goes on to explain that a well-behaved program that wants to trap sigint to do some cleanup, should then disable its handler, and re-kill itself in order to get the correct exit flags set.

Best Answer

Related Solutions

Bash – How to Forward SIGTERM to Child in Bash

Bash – Why does Bash ignore SIGINT if its currently running child handles it

Related Question