Date: Wed, 2 Apr 2014 14:05:56 -0400 From: John Baldwin <jhb@freebsd.org> To: Karl Pielorz <kpielorz_lst@tdx.co.uk> Cc: freebsd-hackers@freebsd.org Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <201404021405.56878.jhb@freebsd.org> In-Reply-To: <B03C862019293A4090837F62@study64.tdx.co.uk> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404021130.39478.jhb@freebsd.org> <B03C862019293A4090837F62@study64.tdx.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, April 02, 2014 12:55:43 pm Karl Pielorz wrote: > > --On 2 April 2014 11:30:39 -0400 John Baldwin <jhb@freebsd.org> wrote: > > >> # ps ax | grep 4344 > >> ps axl | grep 4344 > >> 0 4344 895 0 20 0 84868 6944 urdlck Is - 0:00.01 sshd: > >> unknown [priv] (sshd) > > > > Can you get 'procstat -k 4344' to see where this process is stuck? > > Sure, > > " > # procstat -k 4344 > PID TID COMM TDNAME KSTACK > 4344 100068 sshd - mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_rw_rdlock > __umtx_op_rw_rdlock amd64_syscall Xfast_syscall > " Yes, that is waiting on a pthread read lock as the Xen guys noted. > >> 22 4345 4344 0 20 0 0 0 - Z - 0:00.00 <defunct> > >> 0 4346 4344 0 21 0 84868 6952 sbwait I - 0:00.00 sshd: > >> unknown [pam] (sshd) > > > > 'procstat -f' and 'procstat -k' for this process might also be useful. > > Ok, think you mean PID 4346? > > " > # procstat -f 4346 > PID COMM FD T V FLAGS REF OFFSET PRO NAME > 4346 sshd text v r r------- - - - /usr/sbin/sshd > 4346 sshd cwd v d r------- - - - / > 4346 sshd root v d r------- - - - / > 4346 sshd 0 v c rw------ 6 0 - /dev/null > 4346 sshd 1 v c rw------ 6 0 - /dev/null > 4346 sshd 2 v c rw------ 6 0 - /dev/null > 4346 sshd 3 s - rw---n-- 2 0 TCP 192.168.0.138:22 > 192.168.0.45:54588 > 4346 sshd 5 p - rw------ 2 0 - - > 4346 sshd 6 s - rw------ 2 0 UDS - > 4346 sshd 7 p - rw------ 1 0 - - > 4346 sshd 8 s - rw------ 2 0 UDS - > " > > " > # procstat -k 4346 > PID TID COMM TDNAME KSTACK > 4346 100100 sshd - mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep sbwait soreceive_generic > dofileread kern_readv sys_read amd64_syscall Xfast_syscall > " Grr, I guess that's what I should have expected. Was sort of hoping to be able to see which socket it was blocked on. Can you run 'kgdb' as root (no args), then do 'proc 4346' and 'bt'? If you are familiar with gdb, walk up to the frame that in sys_read and do 'p *uap' so we can see which fd is being read. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404021405.56878.jhb>