Timeline for Why doesn't SIGKILL terminate a stopped program (yes)?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 23, 2023 at 9:35 | comment | added | Gilles 'SO- stop being evil' | @AlexMartian kill returns 0 if it could deliver the signal, which basically means that the PID is valid and the calling process has the appropriate permission. What happens next (signal ignored, signal handler runs, signal kills the process, signal reaction delayed because the target process is in a non-interruptible system call, …) doesn't delay kill returning and doesn't affect its return status even if it hasn't returned yet. | |
| Oct 21, 2023 at 2:59 | comment | added | Alex Martian | @Gilles'SO-stopbeingevil', "suspended process kills it — asynchronously". In that case, what is exit status of a kill command? 0 or 1? | |
| Jun 13, 2015 at 1:22 | comment | added | sapi | While SIGKILL cannot be blocked, there is no guarantee that it will be delivered within any meaningful time. If a process is suspended pending blocking I/O, for example, SIGKILL will not arrive until the process wakes. This could potentially be never, if no I/O occurs. | |
| Jun 12, 2015 at 22:34 | comment | added | Gilles 'SO- stop being evil' | But I can reproduce s1m0n's behavior on my system (Debian, amd64, bash 4.3.30). | |
| Jun 12, 2015 at 22:32 | comment | added | lcd047 | @Gilles That's what I was trying to illustrate above: SIGTERM is blocked, but SIGKILL isn't. Anyway, according to a comment from OP, the problem seems to be that jobs doesn't detect that the process has died, not the process not being killed by kill -9 %1. | |
| Jun 12, 2015 at 22:30 | comment | added | Gilles 'SO- stop being evil' | SIGKILL, unlike other signals, is not blocked for suspended processes. Sending the KILL signal to a suspended process kills it — asynchronously, but in practice basically immediately. | |
| Jun 12, 2015 at 20:45 | history | edited | lcd047 | CC BY-SA 3.0 | added 1 character in body |
| Jun 12, 2015 at 19:35 | comment | added | lcd047 | @mreithub Yes, that's exactly what happens. Well, SIGSTOP is actually sent in very different conditions. | |
| Jun 12, 2015 at 19:24 | comment | added | mreithub | Some background details: When issuing Ctrl+Z in your terminal bash sends a SIGTSTP (which is the blockable version of SIGSTOP) to the active process. This puts the process in a frozen state where the kernel won't schedule it. That also inhibits signal processing (except for the SIGCONT signal which unfreezes the process) and therefore prevents the process from being killed right away. | |
| Jun 12, 2015 at 19:07 | history | answered | lcd047 | CC BY-SA 3.0 |