In Message <pine.neb.4.64.1509241821230.1...@vps1.whooppee.com>,
Paul Goyette <p...@vps1.whooppee.com>wrote:
=>I'm not sure how I got to this point (but see high-level steps below).
=>I have this zombie process:
=>
=>root 27237 0.0 0.0 0 0 pts/2- Z - 0:00.00 (sh)
=>
=>Various web resources say "kill the parent" and the zombie child will
=>die, too. But that's probably not a good idea here, since the parent is
=>(or at least, appears to be) init (pid==1).
Can you conform with "ps axl"?
=>I checked for other potential parents (ie, any process with pts/2 for
=>its TTY), and found two shell processes (one was my "login" shell on
=>that terminal, and the other was the result of a "su" command). I
=>logged out of both processes, but the zombie remained.
=>
=>This is the second time this has happened, and both times were when I
=>was using pkgsrc's mksandbox to rebuild something. The sandbox is
=>"almost" standard, created with this command:
=>
=> # mksandbox --src=/build/netbsd-local/src \
=> --xsrc=/build/netbsd-local/xsrc \
=> --rwdirs=/tmp \
=> /sandbox
=>
=>(I added the rwdirs=/tmp so that /sandbox/tmp would be a memory-based
=>tmpfs filesystem.)
=>
=>I wouldn't usually worry too much about the zombie, but it's running
=>/bin/sh _from_within_the_sandbox_ and therefore its image/text file owns
=>a reference to /sandbox/bin/sh and this reference prevents me from
=>properly unmounting the sandbox.
=>
=>I suppose I could just manually run "umount -f" but I just hate forcing
=>an unmount of an in-use file-system. :)
=>
=>Suggestions?
If init is really its parent, check its "ps axl" output and
check its WCHAN. If it isn't "wait", maybe run "ktruss -p 1" to
get an idea of what it is doing instead of wait*() calls.
Gary Duzan
