4

I have two hotkeys for interactively looking up and killing a process on Linux:

bindsym $mod+k exec --no-startup-id \
    "ps axo pid,cmd | sed 1d | dmenu -i -l 20 | awk '{print $1}' | xargs kill"
bindsym $mod+$sh+k exec --no-startup-id \
    "ps axo pid,cmd | sed 1d | dmenu -i -l 20 | awk '{print $1}' | xargs -s SIGSEGV kill"

The second hotkey is the "try-harder" version for unresponsive targets. What is the most appropriate signal to use here? It seems like an abuse of SIGSEGV since there is no underlying segmentation fault.

signal(2) says

The signals SIGKILL and SIGSTOP cannot be caught or ignored

but in my experience, it is very common for an unresponsive process to survive SIGKILL while dying to SIGSEGV.

What is the "least wrong" way to mercilessly kill a process?

6
  • 10
    "In my experience, it is very common for an unresponsive process to survive SIGKILL": really? Are you sure you were sending SIGKILL? Have you tried with the straightforward kill -9? I very rarely see things survive that. It does happen, but extremely rarely.
    – terdon
    Commented May 21 at 10:26
  • 10
    "it is very common for an unresponsive process to survive SIGKILL while dying to SIGSEGV." are you confusing SIGKILL with SIGTERM, perhaps? The only times I have seen SIGKILL be ineffective are when the process is stuck in uninterruptible sleep (e.g., hung on a network call or other hardware request), and I don't think SIGSEGV would be any luckier in those cases
    – muru
    Commented May 21 at 10:27
  • You are probably correct - I also used SIGTERM for a while, and might be mistakenly associating its results with SIGKILL. I will test some more with SIGKILL.
    – Fadeway
    Commented May 21 at 10:35
  • 2
    One might reply that unconditionally killing a process is never the right way. Something has seriously gone wrong. ;-) Commented May 21 at 20:48
  • 1
    @Fadeway SIGKILL certainly has to work if the process is killable at all (not stuck in the kernel), even if no other signals do. Unlike all the other fatal signals, SIGKILL is not really a signal delivered to the process, it's just telling the kernel "please just destroy this process for me", the process never gets a chance to protest.
    – TooTea
    Commented May 22 at 10:21

1 Answer 1

5

What is the "least wrong" way to mercilessly kill a process?

To mercilessly terminate a process, send a SIGKILL (signal number 9). This signal cannot be ignored by the process. It's like pulling the plug:

kill -9 <pid>
kill -s SIGKILL <pid>

The proper, cleaner way to terminate a process is to send a SIGTERM (signal number 15). This allows the process to do some housekeeping before shutting down. However, it won't (always) work on unresponsive processes.

kill -15 <pid>
kill -s SIGTERM <pid>

SIGSEGV doesn't apply here; it's the signal (SEGmentation Violation) that the OS sends to a process that did a segmentation fault.

4
  • 2
    Is -15/-s SIGTERM actually necessary? I thought kill uniformly defaulted to SIGTERM. Is there a system that differs from that norm? Commented May 21 at 19:18
  • @ShadowRanger Indeed: "If no signal is specified, the TERM signal is sent." Commented May 21 at 19:51
  • 4
    @ShadowRanger That is correct, but outside of interactive usage it’s almost always preferable to be as specific as possible even if it means being verbose. Commented May 21 at 21:22
  • 4
    I would also suggest trying SIGINT and then SIGQUIT. SIGINT because it is very convenient (it's just ^C while the process is in the foreground) and SIGQUIT because it is both convenient (^\) and much, much less likely to be caught or ignored than SIGINT (in particular, Python catches SIGINT but not SIGQUIT).
    – Kevin
    Commented May 22 at 2:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .