7

If I want to kill a process as careful and politely as possible,
which signals should I use in a kill command, in which order?

I would like to give the programm any kind of time to clean up, if it likes to, so just sending a SIGTERM will be to harsh, I think?

I'll use SIGKILL ("-9") last, that's clear.

But which to start? SIGHUP? Which signals are just a waste of time?


The relevant signals for reference, from

man 7 signal

  Signal     Value     Action   Comment
   ──────────────────────────────────────────────────────────────────────
   SIGHUP        1       Term    Hangup detected on controlling terminal
                                 or death of controlling process
   SIGINT        2       Term    Interrupt from keyboard
   SIGQUIT       3       Core    Quit from keyboard
   SIGKILL       9       Term    Kill signal
   SIGPIPE      13       Term    Broken pipe: write to pipe with no
                                 readers
   SIGTERM      15       Term    Termination signal
Volker Siegel
  • 17,283

1 Answers1

14

SIGTERM is the way to go in my opinion. It has works in most of the cases. The ones in which this will not work, you'll have to do a SIGKILL anyway.
SIGTERM gives process enough opportunity to release all the resources it has to and shut down cleanly.

  • Yes, it would work, but I'd like to give the programm a chance to die less hard, if possible. I will make the point more clear. – Volker Siegel Jul 29 '14 at 15:17
  • 1
    @VolkerSiegel Aditya is correct, SIGTERM is the standard – phemmer Jul 29 '14 at 15:20
  • Yes, it's the default, and standard. But for being "friendly" to a programm, it should not be the first signal I think. – Volker Siegel Jul 29 '14 at 15:22
  • @VolkerSiegel Why would it not be "friendly"? – phemmer Jul 29 '14 at 15:23
  • 2
    Many programs are safe to be sent SIGTERM. – 41754 Jul 29 '14 at 15:26
  • Many are save - but not all, and SIGTERM is the most aggressive war to make a program quit. It may not have time to clean up lock files, caches, temporary files, disconect sockets keeping the protocol, etc. – Volker Siegel Jul 29 '14 at 15:34
  • 1
    @VolkerSiegel You're thinking of SIGKILL. – phemmer Jul 29 '14 at 15:36
  • No, SIGKILL is very different - from all other signals: It's not that the process is forced or pressed to exit. The kernel makes the process just stop existing - the process will never even notice. – Volker Siegel Jul 29 '14 at 15:42
  • 6
    @VolkerSiegel You've got 3 different people telling you to use SIGTERM. If you're such an expert on signals, why did you even ask the question? – phemmer Jul 29 '14 at 15:43
  • Because there are some more, and I'm sure they are of use in this situation, at least some times - that's where it get's unclear. (SIGINT and SIGHUP can be useful for sure, SIGQUIT sounds unusual, but SIGPIPE is used all the time in interactive commands, to terminate processes in a friendly way) – Volker Siegel Jul 29 '14 at 15:49
  • 2
    @VolkerSiegel if a program isn't coded to catch SIGTERM and handle it "friendly" then chances are it isn't going to handle SIGINT friendly either. If a program is capable of a "friendly" termination from a signal, SIGTERM is almost assuredly going to be handled. Think of it this way: If you were writing a program that you wanted clean, friendly shutdowns, would you catch SIGINT but ignore SIGTERM? That makes no sense. – casey Jul 29 '14 at 15:50
  • SIGHUP, & SIGPIPE are not used to terminate programs. SIGINT often is, but is not as portable as SIGTERM. No signal, SIGPIPE included, has any relation to whether a program is being run interactively. – phemmer Jul 29 '14 at 15:51
  • 1
    INT, HUP, PIPE, and QUIT have specific meanings. They're not generic 'please terminate' signals. TERM is. – derobert Jul 29 '14 at 15:52
  • Good point - a lot of the question depends on what the program does. That is, what common programs do - much is about the programming side, not the signal handling side, I did not take that into account that much. – Volker Siegel Jul 29 '14 at 15:53
  • @VolkerSiegel - the reason you often wind up having to use the signals these others say you do is because you can't be sure the program will do what you want when you kill it otherwise - not if it's not your own program. You should listen to them. Programs can setup weird handlers for any signal. – mikeserv Jul 29 '14 at 16:21
  • 1
    @mikeserv Oh, I'm actually not disagreeing with them - it's more that I did not get the main points of my question across, I supposse. I'm thinking of something like kill -A $PID && kill -B $PID && kill -TERM $PID && kill -KILL $PID - always trying SIGTERM and SIGKILL in the end anyways, there's not disagreement that they are needed. But wat about A, B, C - which make sense, even if some times, and why/why not. I should add this example, obviously... – Volker Siegel Jul 29 '14 at 16:28
  • @Patrick - SIGPIPE is used to kill programs all the time - it's the signal seq 1000000 | read that seq gets there, else it would just keep trying to write to the broken pipe. – mikeserv Jul 29 '14 at 16:29
  • @VolkerSiegel - gotcha - so start nice, get mean, right? Well, these others know better. You might consider an edit though to make it clear. – mikeserv Jul 29 '14 at 16:29
  • @mikeserv Yes, regarding SIGPIPE - that's what I'm thinking of. It's used to kill in "standard" case. A daemon for example has no pipe, and could somehow misuse that. (I guess SIGPIPE is used cleanly for the official case only, but for signals 1, 2 and 3, the "official" case is less clear to start with). SIGHUB is used by shells to terminate on closing connection ("hangup"), and by daemons to reload config - sometimes. I still think the signals are interesting. But this question did not work out, I guess... – Volker Siegel Jul 29 '14 at 16:43