I will try some of the ideas you guys have posted later, but so far the only thing I found out is that if I kill the window the process would top.
I have never run into this stuation..oh well..... thanks, Nestor :-) On 3/3/06, James G. Sack (jim) <[EMAIL PROTECTED]> wrote: > 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 > -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
