You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// TODO: this should be SIGINT, but will be a breaking change
ifintSignal==Signal(0) {
intSignal=SIGTERM
}
When we send SIGTERM to a process group, bash exits without waiting on its child processes to exit safely. In many cases, the child processes end from other effects, such as SIGPIPE caused by trying to read or write over an orphaned pipeline. This unreliability can lead to lost output or incorrect shutdowns of subprocesses. A script author could potentially work around this using a signal handler. A better approach would be to send a SIGINT signal instead, which will be followed by a SIGKILL if the group takes too long to respond. SIGINT only gets propagated to foreground child processes, so special case handling will still be required for users who are backgrounding processes.
Most processes treat SIGINT the same as SIGTERM, but we can't be sure if anyone is relying on this behaviour. Therefore, this should be considered a breaking change. A user can experiment with this change ahead of time by using the configurable cancel signals introduced by #1041 and #1390.
I've tried to carefully research this and get the above details correct, but please feel free to contribute any corrections or details I might have missed.
The text was updated successfully, but these errors were encountered:
Interesting — have you come across any good links explaining the differences between SIGINT and SIGTERM?
My understanding over the years has stopped at “SIGINT is usually ctrl-c, SIGTERM is usually kill or program-initiated termination, SIGKILL is the kernel just no longer scheduling the process”. I never knew any difference with SIGINT vs SIGTERM around how it's propagated in progress groups between process leader / others processes and/r foreground processes. My understanding of process groups overall is pretty sketchy.
Got any links to things that explain SIGTERM vs SIGINT behaviour?
For historical reasons when we send interrupts to process groups, we default to using
SIGTERM
:agent/process/signal.go
Lines 35 to 38 in b9bc5ec
When we send
SIGTERM
to a process group, bash exits without waiting on its child processes to exit safely. In many cases, the child processes end from other effects, such asSIGPIPE
caused by trying to read or write over an orphaned pipeline. This unreliability can lead to lost output or incorrect shutdowns of subprocesses. A script author could potentially work around this using a signal handler. A better approach would be to send aSIGINT
signal instead, which will be followed by aSIGKILL
if the group takes too long to respond.SIGINT
only gets propagated to foreground child processes, so special case handling will still be required for users who are backgrounding processes.Most processes treat
SIGINT
the same asSIGTERM
, but we can't be sure if anyone is relying on this behaviour. Therefore, this should be considered a breaking change. A user can experiment with this change ahead of time by using the configurable cancel signals introduced by #1041 and #1390.I've tried to carefully research this and get the above details correct, but please feel free to contribute any corrections or details I might have missed.
The text was updated successfully, but these errors were encountered: