16

How do I end all processes with the same name in a more gentle way than killall does? I don't want to interrupt the processes, but leave them time to properly quit.


See also:

How do I kill processes in Ubuntu?

In System monitor, what is the difference between Kill Process and End Process?

Why does killall (sometimes?) needs to be applied twice?

tl;dr

42

1. `killall` already nice (SIGTERM)

killall by default sends SIGTERM. This is already the nice approach that leaves applications the chance to clean up after themselves. The "go die already, right now!" approach is to send a SIGKILL signal, which requires specifying that as an option to killall. From The GNU C Library: Termination Signals:

Macro: int SIGTERM

[...] It is the normal way to politely ask a program to terminate.


2. System Monitor's "End process" equally nice (SIGTERM, too)

You link to a question about GNOME System Monitor. That does use SIGTERM for its "End process" action too (and I realise I am contradicting the answer to that question). You can find it in the source code to verify yourself:

data/menus.ui:

<item>
  <attribute name="label" translatable="yes">_End</attribute>
  <attribute name="action">win.send-signal-end</attribute>
  <attribute name="accel">&lt;Primary&gt;e</attribute>
  <attribute name="target" type="i">15</attribute>
</item>

The 15 here is the signal number. Signal 15 is SIGTERM. And System Monitor has used SIGTERM well before that other question was asked and answered.


Technical addendum (in response to a comment)

Looking through the Github representation of git blame, here are the changes that have been made to how the signals are spelt out in the source code of GNOME System Monitor:

383007f2 24 Jul 2013 Replaced duplicated code for sending signals with GAction parameters
0e766b2d 18 Jul 2013 Port process popup menu to GAction
97674c79 3 Oct 2012 Get rid of ProcData structure
38c5296c 3 Jul 2011 Make indentation uniform across source files.

None of these changed from SIGQUIT to SIGTERM, and that last one was from before the linked question was asked.

  • 7
    +1 for referring to source code ! ( +2 for contradicting "conventional wisdom", as it were ;) – nutty about natty Sep 21 '15 at 14:07
  • Well, before stating that you are contradicting the answer: did you check that all versions of the source code use 15? It may have been changed at some point so the old answer could be 100% right with respect to an old version. – Bakuriu Sep 21 '15 at 18:08
  • 1
    @Bakuriu I do contradict that answer either way, but fair point, I will try to remember to check that next time I can. – hvd Sep 21 '15 at 21:26
  • @Bakuriu in the source git tree, git grep 'SIGQUIT' doesn't reveal anything. Nothing related to signals is found for git grep '>3<' either. I conclude that most likely gnome-system-monitor has never used SIGQUIT. – Ruslan Sep 22 '15 at 5:30
  • @Ruslan git grep only searches the current tree, not the whole history. I used git blame (actually the Github equivalent) to dig a bit deeper, but still nothing. – hvd Sep 22 '15 at 7:59
5

The answer by @hvd is basically correct. To back that up even more, the init process will first send SIGTERM to processes when your are shutting down your computer, then after a delay will send SIGKILL if they have not already exited. Processes can't handle/ignore SIGKILL.

To give a bit more detail though, the real answer is that you have no way of knowing for sure that the program handles it. SIGTERM is the most usual signal to use for politely asking a program to quit, but all signal handling depends on the program doing something with the signal.

To put it a different way, based on the other answers, if you had a program written by @Jos or by @AlexGreg then they would presumably be handling SIGQUIT but possibly not SIGTERM, and hence sending SIGTERM would be less "soft" than SIGQUIT.

I've written some code so you can play around with it yourself. Save the below as signal-test.c, then compile with

gcc -o signal-test signal-test.c

You can then run it ./signal-test, and see what happens when you send different signals with killall -s <signal>.

#include <stdio.h>
#include <signal.h>
#include <unistd.h>

int flag = 0;

void handle_signal(int s)
{
    flag = s;
}

int main(int argc, char *argv[])
{
    signal(SIGTERM, handle_signal);
    signal(SIGQUIT, handle_signal);

    while(flag == 0){
        sleep(1);
    }
    printf("flag is %d\n", flag);
    return flag;
}

As it stands, the code handles both SIGTERM and SIGQUIT gracefully. You could try commenting out the lines signal(SIG... (using a // at the start of the line) to remove the signal handler, then run and send the signals again. You should be able to see these different outputs:

$ ./signal-test
Terminated

$ ./signal-test
Quit (core dumped)

$ ./signal-test
flag is 15

$ ./signal-test
flag is 3

depending on whether you handle the signals or not.

You could also try ignoring the signals:

signal(SIGTERM, SIG_IGN);

If you do that then sending SIGTERM will do nothing, you'll have to use SIGKILL to end the process.

More details in man 7 signal. Note that using signal() in this way is considered non-portable - it's lots easier than the alternative though!

One other minor footnote - on Solaris killall attempts to kill all processes. All of them. If you run it as root then you may be surprised :)

  • 1
    This is one of the reasons I prefer pkill. The other reason is that it pairs with pgrep, which makes it easier to check exactly what processes will be killed, and which itself has better matching semantics than ps | grep. – Random832 Sep 21 '15 at 20:40
2

"End all" would be killall -s SIGQUIT [process name]. If you want a fancy solution, define alias endall='killall -s SIGQUIT'.

  • 12
    SIGQUIT is like making the process abort(3): it dumps core and then kills the process. This is in no way nicer/gentler/kinder than SIGTERM which is default for killall. – Ruslan Sep 21 '15 at 14:02
  • 2
    For a process that handles signals, SIGQUIT (or even better, SIGINT) might be treated more 'softly' than SIGTERM, but this is up to the application. Unhandled, any of them cause immediate termination. – R.. Sep 21 '15 at 15:33
  • This is a great idea, if you like cleaning up core files all over your disk. – Nate Eldredge Sep 21 '15 at 23:25
  • I'd like to re-iterate @R..'s point: Unhandled, any of them cause immediate termination. Signals are a convention on the application's end. What they actually do is up to the application, though the kernel does treat them a bit differently. – Qix Sep 22 '15 at 2:30
  • 2
    @Qix: One thing that varies per signal is whether it creates a core file or not on the default action (when not handled by the application). It's probably preferable to use signals that don't generate core files. – R.. Sep 22 '15 at 3:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.