Bash – How to Forward SIGTERM to Child in Bash

bashdockershellsignals

I have a Bash script, which looks similar to this:

#!/bin/bash
echo "Doing some initial work....";
/bin/start/main/server --nodaemon

Now if the bash shell running the script receives a SIGTERM signal, it should also send a SIGTERM to the running server (which blocks, so no trap possible). Is that possible?

Best Answer

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).

Related Solutions

Bash does not exit on abnormal exit of child process due to signal

First, exit 130 is not an abnormal exit. It is a normal exit, with exit status 130. As can be seen from man 3 wait (POSIX):

   If  the  information  pointed  to  by  stat_loc was stored by a call to
   waitpid()  that  specified  the  WUNTRACED     and  WCONTINUED   flags,
   exactly one of the macros WIFEXITED(*stat_loc), WIFSIGNALED(*stat_loc),
   WIFSTOPPED(*stat_loc),  and WIFCONTINUED(*stat_loc)  shall evaluate  to
   a non-zero value.

WIFEXITED checks normal exit, and WIFSIGNALLED is termination due to an uncaught signal. Since these are mutually exclusive, an exit 130 is normal.

That the exit status is 130 when a process dies by SIGINT is because bash sets it to be 130 outside of the process because it detected an exit due to SIGINT: Why does bash set $? (exit status) to non-zero on Ctrl-C or Ctrl-Z?

Second, a process that handles SIGINT and then dies should kill itself with SIGINT. Greg's wiki (an excellent resource for shell stuff) has a note on this:

If you choose to set up a handler for SIGINT (rather than using the EXIT trap), you should be aware that a process that exits in response to SIGINT should kill itself with SIGINT rather than simply exiting, to avoid causing problems for its caller. Thus:
trap 'rm -f "$tempfile"; trap - INT; kill -INT $$' INT

Now, if you changed the exit 130 to:

trap - INT
kill -INT $$

You'd see the expected behaviour.

Linux Signals – Must SIGKILL and SIGTERM Be Explicitly Sent to a Process?

As far as I can tell, the Linux kernel doesn’t send SIGTERM on its own to user processes. (SIGTERM is used internally with kernel threads: that’s how the kernel asks a kernel thread to stop.)

The kernel does send SIGKILL to user processes of its own accord, in a number of circumstances. For example, the OOM killer kills its target with SIGKILL; some kernel oops result in a SIGKILL; various memory failures can result in SIGKILLs.

When the operating system shuts down, processes are shut down using SIGTERM and SIGKILL, but those signals don’t come from the kernel (or not directly — calling kill() with a pid of 0 or a negative pid will result in the kernel sending the signal to a number of processes). They come from a service manager terminating its services and from various last-ditch-kill-everything application-mode programs that are part of the system management mechanism: e.g. the killprocs van Smoorenburg rc script, the killprocs OpenRC script, and the systemd-shutdown program.

When the kernel shuts down, or reboots, it doesn’t care about processes and doesn’t kill them (see reboot() for details; ignore the LINUX_REBOOT_CMD_RESTART2 variant of the system call, you can’t use the command argument to handle processes).

Best Answer

Related Solutions

Bash does not exit on abnormal exit of child process due to signal

Linux Signals – Must SIGKILL and SIGTERM Be Explicitly Sent to a Process?

Related Question