Pete French wrote:
> I updated to stable yesterday, plus updated all my porst to
> the latest pecompiled packages, but I am now seeing odd problems
> with bash on exit. Sometimes it quits, but leaves a zombie
> process... e.g
>
> PID TT STAT TIME COMMAND
> 44308 v0 IW 0:00.00 -bash (bash)
> 44312 v0 IW+ 0:00.00 /bin/sh /usr/local/bin/startx -listen_tcp
> 44325 v0 IW+ 0:00.00 xinit xterm -listen_tcp -- /usr/local/bin/X :0
> -auth /ho
> 44328 v0 IW 0:00.00 /usr/local/bin/wmaker
> 44340 v0 S 0:03.35 /usr/local/bin/wmaker --for-real
> 49101 0- Z+ 0:02.73 <defunct>
> 49314 1- Z+ 0:00.17 <defunct>
> 56068 2 Ss 0:00.01 bash
> 56498 2 R+ 0:00.00 ps
> 56074 3 Is 0:00.01 bash
> 56076 3 S+ 0:00.00 mail freebsd-stable at freebsd.org
> 56308 4 Is+ 0:00.01 bash
>
> Thats the current 'ps' on this machine. The bash processes are
running
> inside an xterm, so am not sure if the issue is with bash or the
> terminal. Kind of puzzled!
I can reproduce this easily, although not every time.
Running 10.2 under KDE, with bash as a default shell:
start xterm from a KDE 'konsole', then move to within the xterm
and try closing it (^D or exit). More often than not the xterm
will block and stay open, the bash process within goes <defunct>.
A normal kill of xterm has no effect, although a kill -9 to the
xterm blows away the xterm and the init process then clears
the bash zombie leftover. Seems like running a simple command
like 'date' in xterm before trying to close it does increase
the likelihood that xterm will block on exit.
> Currently I have to reboot the machine periodicly once I have
> accumulated
> enough zombies to be annoying. Its not really a long term solution
> though.
There is no need to reboot, just kill -9 the hanging xterm processes
and the init will clear the zombies.
Mark