Skip to main content
7 events
when toggle format what by license comment
Sep 29, 2024 at 14:19 comment added Stéphane Chazelas @ZoltanK. there is no propagation, whatever that means, just that ^C causes SIGINT to be sent to the foreground process group, all processes in that group. If you send SIGTERM to the whole process group, as with kill -- "-$pgid", you'll see all processes dying, and if the shell is waiting for a process that handles/ignores that signal, you'll see bash does not treat it specially like it does for SIGINT/SIGQUIT
Sep 29, 2024 at 13:57 comment added Zoltan K. Reading through the source you have kindly provided about "wait and cooperative exit", SIGTERM is not under the umbrella of this behaviour. In this answer: stackoverflow.com/a/34225945/7025033 , it is claimed that SIGTERM is not propagated, and this is indeed what I see when I tested it. Even if the subshell of sleep is not backgrounded, only the main shell is terminated, the sleep keeps on running. So, if SIGTERM were to be sent to the whole process group, there would be a race condition, the outcome depends on the order in which the processes are terminated.
Sep 29, 2024 at 13:46 comment added Zoltan K. I just checked the same with SIGTERM, in which case it works as you have described.
Sep 29, 2024 at 13:37 comment added Zoltan K. On the last part of your answer and my second case, the backgrounded subshell: I checked it in my shell and Ctrl+C kills everything: the foreground and the background process, no sleep remains. I made sure I actually use a bash shell. I trapped SIGINT to make sure that that is what Ctrl+C sends. I have also checked my .bashrc, but nothing stood out as relevant in this matter. Could you confirm the behaviour you described on your system?
Sep 29, 2024 at 12:50 history edited Stéphane Chazelas CC BY-SA 4.0
added 16 characters in body
Sep 29, 2024 at 8:06 history edited Stéphane Chazelas CC BY-SA 4.0
added 154 characters in body
Sep 29, 2024 at 7:49 history answered Stéphane Chazelas CC BY-SA 4.0