On Sat, 19 Jan 2002 13:52:25 -0500, dman <[EMAIL PROTECTED]> wrote: > On Sat, Jan 19, 2002 at 08:15:49AM +0800, csj wrote: > | On Thu, 17 Jan 2002 19:42:40 -0600 > | Nori Heikkinen <[EMAIL PROTECTED]> wrote: > | > | > on Thu, 17 Jan 2002 11:33:25PM +0200, Ian Balchin insinuated: > | > > I locked up mutt & jove while editing a message. I killed them from > | > > top but cannot get use of tty1 back which still shows the process. > | > > > | > > I do not want to reboot. Any magical suggestions which rtfm to > | > > examine? > | > > | > ps aux | grep tty1 > | > kill -9 [pid of tty1] > | > | Is there anything more drastic than -9 (short of rebooting)? > > nope. processes aren't allowed to handle signal 9 so they can't block > it like they can with 15 or 11. > > | How do I terminate the living dead? > | > | alpha:~# ps -A | grep defunct > | 31080 ? 00:00:00 gpg <defunct> > | 31081 ? 00:00:00 gpg <defunct> > | alpha:~# kill -9 31080 > | alpha:~# ps -A | grep defunct > | 31080 ? 00:00:00 gpg <defunct> > | 31081 ? 00:00:00 gpg <defunct> > | > | And here's top's top: > | > | 08:11:45 up 5 days, 17:10, 6 users, load average: 0.07, 0.03, 0.00 > | 94 processes: 91 sleeping, 1 running, 2 zombie, 0 stopped > > Those processes are blocked on IO or something. Thus it is the > _kernel_ itself that is stuck, which is why SIGKILL has no effect. > When a process is executing in its own space, the kernel can kill it > and clean up the pieces. When the process is executing inside the > kernel (in a system call) then the kernel can't blow it away because > it would then need to somehow put itself back together.
I believe those are zombies of one or more forked processes. They're kept around so the parent can do a waitpid() on them. Other than a PID, they shouldn't be taking up any memory or other resources. Sylpheed is notorious for creating gpg zombies.... They'll dissappear when the parent exits. -- Eric G. Miller <egm2@jps.net>
