7

I've an annoying process that won't die:

ps -A | grep "nzbget"

gives me:

11394 pts/3    00:00:00 nzbget

If I try:

pkill nzbget (or 11394)

...I get no response and the process is still alive, top gives me:

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
11394 asystem+  20   0  125448   6244   4984 T   0.0  0.1   0:00.00 nzbget

I run nzbget with 'nzbget -s', if I do this after it is running (and I've tried to stop it), I get a [binding socket failed] error and all I can do is reboot.

How can I kill this off without rebooting?

aSystemOverload
  • 731
  • I might possibly have just forgot to use sudo/su, as I didn't get a response, I just presumed it had worked ok (or not had errors). Just did [sudo kill -9 nzbget] and it responded with [[2]+ Killed nzbget -s.] So all good. – aSystemOverload Dec 22 '14 at 22:41
  • 1
    By the way, it is very easy to write unkillable process. For example, simple try: pass except: pass in loop in Python becomes an unkillable process. To stop them, use kill -9 or killall -s SIGKILL dude or pkill -9 dude – Barafu Albino Dec 23 '14 at 13:17

5 Answers5

9

As the process is stopped* (notice the T as the state output in top), it is unable to do any signal handling at all. So, you need to use a signal that does not require process interaction, in your case SIGKILL (9) as in the following

kill -9 11394

If you want, for whatever reason, get a core dump of the process (and your system is configured for that), you could use SIGSEGV (11) instead. This does not require any process interaction either.

* I assume stopped here, because a traced process should be able to handle signals, which may lead to the process being stopped.

Abrixas2
  • 878
  • 6
    +1: The only answer (so far) to recognise the T state of the process. You could also send a SIGCONT to the process and any queued signals will be delivered. i.e. if you've already run pkill (and sent a SIGTERM), if you then send a SIGCONT, the process will be started and the SIGTERM will be delivered. – camh Dec 23 '14 at 03:23
  • @camh your comment is the only answer to correctly mention SIGCONT. Please post this as a separate answer ;-) – mirabilos Dec 23 '14 at 09:15
7

You can use kill -9 11394 to kill the process completely ungracefully, this will invoke the following:

From The 3 most important "kill" signals on the Linux/UNIX command line:

The kernel will let go of the process without informing the process of it. An unclean kill like this could result in data loss. This is the "hardest", "roughest" and most unsafe kill signal available, and should only be used to stop something that seems unstoppable.

Mat
  • 52,586
Chris Davidson
  • 1,467
1

Try using the signal flag to gracefully kill the process:

kill -15 11394

ryekayo
  • 4,763
1

There are various signals you can try, which I am sure someone else will list, but the one I find most effective is the HUP signal:

kill -hup 11394

I find this works in a lot of cases where the application isn't responding to any other signals. Failing that you can just do kill -9, though this may have side effects since it just pulls the plug and doesn't let the application clean up.

Graeme
  • 34,027
1

In the case of an X app, I have had luck using xkill and clicking its window when the app wouldn't respond to a kill from the command line

BORIUO
  • 21
  • 1