How to kill - softly?

process kill zombie-process

8,843

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.

8,843

Volker Siegel

I like to answer older questions, if I have an additional perspective to the question to give. Adding an additional answer even if there are valid answers can still add value to the collection of answers and questions we are building here. (A late answer does, by it's nature, get not much attention, so it leads to exceptionally low reputation per answer. But hey, that's life, right?) And I feel it's the important thing here: We're answering professional questions in a professional way, and often do that quickly. That's of great value for the general public. But the real thing of value, that is of value hard to describe in simple terms, is the body of text, the whole collection that we are creating here together. All participants here, whether he or she cares more about asking, answering or collecting questions and answers. This applies to all StackExchange sites and topics in the same way. In some sites and topics, I like to add questions that have only the purpose of growing the collection, often more academic than practical, and of general interest while not too trivial. I'm here because I want to take part in the creation of this exceptional body of well structured knowledge.

Updated on September 18, 2022

Comments

Volker Siegel over 1 year
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
```
- Admin almost 10 years
  
  unix.stackexchange.com/questions/19474/…
- Admin almost 10 years
  
  Did you read this:unix.stackexchange.com/questions/8916/…
- Admin almost 10 years
  
  This has a partial answer regarding the signal order (contradicting the order in the other references): Ignacio Vazquez-Abrams on When you try to terminate a process for good, which option for “kill” should you use?
Volker Siegel almost 10 years

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.
phemmer almost 10 years

@VolkerSiegel Aditya is correct, SIGTERM is the standard
phemmer almost 10 years

@VolkerSiegel Why would it not be "friendly"?
41754 almost 10 years

Many programs are safe to be sent SIGTERM.
Volker Siegel almost 10 years

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.
phemmer almost 10 years

@VolkerSiegel You're thinking of SIGKILL.
Volker Siegel almost 10 years

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 almost 10 years

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)
casey almost 10 years

@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.
phemmer almost 10 years

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.
derobert almost 10 years

INT, HUP, PIPE, and QUIT have specific meanings. They're not generic 'please terminate' signals. TERM is.
Volker Siegel almost 10 years

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.
mikeserv almost 10 years

@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.
Volker Siegel almost 10 years

@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...
mikeserv almost 10 years

@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 almost 10 years

@VolkerSiegel - gotcha - so start nice, get mean, right? Well, these others know better. You might consider an edit though to make it clear.
Volker Siegel almost 10 years

@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...