Shell – Why is `kill -s INT ` behaving differently from `Ctrl-C`

killshellsignalszsh

Starting with:

% donothing () { echo $$; sleep 1000000 }
% donothing
47139

If at this point I hit Ctrl-C at the same terminal that is controlling the shell, then the function donothing does indeed terminate, and I get the command prompt back.

But if instead, from a different shell session, I run

% kill -s INT 47139

…the donothing function does not terminate. (Ditto if I pass -47139 as the last argument to kill.)

Do I need to use a different PID from the one I'm using to achieve with kill -s INT the same effect that I can achieve interactively with Ctrl-C at the controlling terminal?

(I'm primarily interested in the answer for zsh.)

EDIT: in response to Gilles comment: no, I have not set any traps (though I would be interested to learn how to confirm that no traps are set: is there a way to list all the active traps?); and yes, I can reproduce this behavior with zsh -f. In fact, I can reproduce it under the most extreme way I know to get an absolutely "bare" zsh (please let me know if there's a better way):

% /usr/bin/env -i /usr/bin/zsh -f
% donothing () { echo $$; sleep 1000000 }
12345

…etc.

Since my original post, I have replicated the behavior described above both under Darwin and under NetBSD, but not under Linux (i.e. under Linux kill -s INT <zsh PID> does kill the donothing function defined above, without killing the parent shell in the process).

So maybe this is a BSD-ish thing. More specifically, in every Unix I've tried this with, the sleep process is a child of the zsh process, but only under Linux is the SIGINT signal that was sent to the zsh process propagated to the sleep process.

Therefore, in order to be able to kill the donothing function non-interactively under Darwin and NetBSD I need a way to find the PID of the sleep-ing child, and send the SIGINT to it (which, admittedly, does sound pretty heartless). More generally, to kill a shell function non-interactively under Darwin and NetBSD, I need to recursively/depth-first find the descendants of the zsh process and send them the SIGINT to them…

Best Answer

Control-c from the terminal sends an interrupt signal to the process group associated with the terminal, which includes the sleep process. Sending SIGINT via kill only reaches one process, and in this case it happens to be the wrong process because $$ returns the process ID of the shell, not the sleep process. Shells normally ignore SIGINT.

Related Solutions

Why would Ctrl-C behave differently than kill -2

One possibility is that the program catches the Ctrl+C sequence. Check the output of stty -a; the intr setting indicates which key combination (if any) sends a SIGINT signal, and the isig indicates whether the signal keys are enabled (-isig means they are disabled).

If the program consists of several processes, pressing Ctrl+C sends SIGINT to all the processes in the process group. You can obtain the same effect by sending the signal to the process group instead of sending it to one of the processes. To send a signal to a process group, first determine its leader: that's the first process that starts all the others; if you run the process group in the background, that's the PID shown by jobs -l. The PID of the process group leader is the PGID (process group id); send the signal to its negative. E.g. if the PGID is 1234, run kill -INT -1234.

If the program consists of a wrapper script and a main application, there are two cases to consider. If there is no cleanup to do, so that the wrapper script terminates as soon as the main aplication terminates, make the wrapper script call exec:

#!/bin/sh
export SOMEVAR=somevalue
…
exec /path/to/application "$@"

This way the application replaces the script, inheriting its PID. Some shells optimize a script that ends by executing another program, but not all. This approach doesn't work when the script needs to perform some cleanup such as removing temporary files.

Consider making the script detect a signal and transmitting the signal to the application. Here's a sketch of how this goes:

/path/to/application "$@" &
app_pid=$!
trap -INT 'kill -INT $app_pid'
wait $!
rm /temp/file

Kill a group of processes with negative PID

Does it say "no such PID" or is there an error, - as in does this work?

kill -TERM -- -GPID

Also note, as per (emphasize mine)
man 1:

"[…] When an argument of the form '-n' is given, and it is meant to denote a process group […]"

man 2:

"[…] If pid is less than -1, then sig is sent to every process in the process group whose ID is -pid. […]"

man 3:

"[…] If pid is negative, but not -1, sig shall be sent to all processes (excluding an unspecified set of system processes) whose process group ID is equal to the absolute value of pid, […]"

As in, not PID but process group ID.

Else perhaps you can have so fun with /proc/[pid]/stat

ppid: awk '{gsub(/\([^)]+\)/,"_"); print $4}' /proc/3955/stat
pgrp: awk '{gsub(/\([^)]+\)/,"_"); print $5}' /proc/3955/stat

pkill -TERM -g PGRP

Best Answer

Related Solutions

Why would Ctrl-C behave differently than kill -2

Kill a group of processes with negative PID

Related Question