Stuck CLOSED sockets / sshd / zombies...

[John Baldwin]

On Thursday, April 03, 2014 11:59:07 am Karl Pielorz wrote:
> 
> --On 03 April 2014 11:03 -0400 John Baldwin <jhb at freebsd.org> wrote:
> 
> > Hmm, that fd value doesn't make any sense now.  Do you have the backtrace
> > for that process?  The fd may show up in the arguments to kern_readv().
> 
> Ok, bt shows:
> 
> "
> #0  sched_switch (td=0xfffff800238bb920, newtd=<value optimized out>, 
> flags=<value optimized out>) at ../../../kern/sched_ule.c:1938
> #1  0xffffffff808be76e in mi_switch (flags=260, newtd=0x0) at 
> ../../../kern/kern_synch.c:494
> #2  0xffffffff808f9002 in sleepq_catch_signals (wchan=0xfffff80002da4c24, 
> pri=104) at ../../../kern/subr_sleepqueue.c:429
> #3  0xffffffff808f8eaf in sleepq_wait_sig (wchan=0x0, pri=0) at 
> ../../../kern/subr_sleepqueue.c:634
> #4  0xffffffff808be195 in _sleep (ident=<value optimized out>, lock=<value 
> optimized out>, priority=360, wmesg=0xffffffff80efbd30 "sbwait",
>     sbt=<value optimized out>, pr=0, flags=<value optimized out>) at 
> ../../../kern/kern_synch.c:254
> #5  0xffffffff8092328c in sbwait (sb=<value optimized out>) at 
> ../../../kern/uipc_sockbuf.c:130
> #6  0xffffffff80926b44 in soreceive_generic (so=0xfffff80002da4ae0, 
> psa=0x0, uio=0xfffffe0000341ab0, mp0=0x0, controlp=0x0, flagsp=0x0)
>     at ../../../kern/uipc_socket.c:1496
> #7  0xffffffff8090346b in dofileread (td=0xfffff800238bb920, fd=8, 
> fp=0xfffff80002cf86e0, auio=0xfffffe0000341ab0, offset=<value optimized 
> out>, flags=0)
>     at file.h:295
> 
> 
> #8  0xffffffff809031a5 in kern_readv (td=0xfffff800238bb920, fd=8, 
> auio=0xfffffe0000341ab0) at ../../../kern/sys_generic.c:256
> 
> 
> #9  0xffffffff80903133 in sys_read (td=<value optimized out>, uap=<value 
> optimized out>) at ../../../kern/sys_generic.c:171
> #10 0xffffffff80c96cd7 in amd64_syscall (td=0xfffff800238bb920, traced=0) 
> at subr_syscall.c:134
> #11 0xffffffff80c7d3fb in Xfast_syscall () at 
> ../../../amd64/amd64/exception.S:391
> #12 0x000000080320d9ea in ?? ()
> "
> 
> So, fd=8? - fstat seems to show that as:
> 
> "
> USER   CMD     PID  FD MOUNT  INUM MODE         SZ|DV R/W
> root   sshd   4346   8* local stream fffff80002e55c30 <-> fffff80002e552d0
> ...
> root   sshd   4344   4* local stream fffff80002e552d0 <-> fffff80002e55c30
> "

Right, so it's just blocked on a UNIX domain socket from the parent waiting
for the parent to tell it to do something.  The root issue is the parent
(as I feared).  Is 4344 threaded (procstat -t?)

-- 
John Baldwin