John H. Robinson, IV wrote:
James G. Sack (jim) wrote:
3) suspend the program with Ctrl-Z (SIGSTOP), then kill %+
(or %1, or, ..)
When you send a process a SIGSTOP then a SIGTERM, you want to send it a
SIGCONT also so it can process the SIGTERM. Oftimes, this is not
required. You can check the status with jobs at the command line.
Easy ways to give a SIGCONT: fg or bg
Well, I was talking about my experiences with processes started from a
(bash) shell, I have found that kill %+ of a sleeping job (when issued
from the same shell, of course, else %+ wouldn't be defined) needs no
subsequent fg or bg. Or, maybe that's bash-specific -- jhriv-- is zsh
different in this respect?
..
Is there anything I can do to make sure that the process is kill
when I do a 'kill -9 processid'
The process itself never receives the SIGKILL. The kernel handles that.
If there is a blocked I/O, the process will hang around waiting for the
I/O to complete. There is nothing you can do, except to somehow make the
I/O complete. I cannot give further guidance than that.
Yep, if the process is blocked on i/o in "uninterruptible sleep" mode
indicated by a 'D' in the STAT field of the ps display, there seems to
be no way to get rid of it. You can kill its parents/children, but the
'D' process itself lives until it gets it's i/o event (which may never
occur).
The only other solution is to reboot. That clears out all outstanding
(and even mediocre ;) I/O connections.
I've often wondered why someone can't figure a way to kill processes in
uninterruptible sleep. I guess there's some difficulty meddling with
kernel queues, and I suppose the cost of immortal D-state processes is
not that great, but it's a recurring annoyance.
..jim
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
