Re: Process stuck in D+ state

On 2013-10-13 15:10, Olivier Cochard-Labbé wrote:
> I've got a frequent problem on my desktop (FreeBSD 10.0-ALPHA5 #8 r256200):
> After few hours I can't acces to one of my folder: A simple "ls" in
> this folder stucks, and all filesystem information started after (df,
> fstat) stuck too in D+.
>
> SIGINFO report this usage for these processes:
>
> load: 0.15  cmd: ls 15716 [rpcrecon] 217.89r 0.00u 0.00s 0% 2440k
> load: 0.34  cmd: ls 15716 [connec] 2376.60r 0.00u 0.00s 0% 0k
> load: 0.40  cmd: ls 15716 [connec] 2379.80r 0.00u 0.00s 0% 0k
> load: 0.40  cmd: ls 15716 [connec] 2379.92r 0.00u 0.00s 0% 0k
> load: 0.37  cmd: ls 15716 [rpcrecon] 2850.26r 0.00u 0.00s 0% 0k
> load: 0.37  cmd: ls 15716 [rpcrecon] 2850.39r 0.00u 0.00s 0% 0k
>
> load: 0.40  cmd: fstat 15781 [rpcrecon] 2842.08r 0.00u 0.01s 0% 0k
> load: 0.21  cmd: fstat 15781 [rpcrecon] 2879.35r 0.00u 0.01s 0% 0k
> load: 0.21  cmd: fstat 15781 [rpcrecon] 2879.48r 0.00u 0.01s 0% 0k
> load: 0.21  cmd: fstat 15781 [rpcrecon] 2879.63r 0.00u 0.01s 0% 0k
>
> load: 0.24  cmd: df 15919 [connec] 1047.98r 0.00u 0.00s 0% 0k
> load: 0.22  cmd: df 15919 [connec] 1054.22r 0.00u 0.00s 0% 0k
>
> and the PS status:
>
> olivier    15919   0.0  0.0   14400     16  7  D+    7:06PM     0:00.01 df -h
> olivier    15781   0.0  0.0   20708     16  6  D+    6:26PM     0:00.02 fstat
> olivier    15651   0.0  0.0   16784     16  4  D+    6:25PM     0:00.00 ls
>
> My desktop use a geli system and JSU, nothing special, here are the mount point:
> /dev/ada1p3.eli on / (ufs, local, noatime, journaled soft-updates)
> devfs on /dev (devfs, local, multilabel)
> /dev/gpt/boot on /boot2 (ufs, local, noatime, soft-updates)
>
> What kind of commands can I use for getting more troubleshooting(
> information next time ?
>
> Thanks
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
Looking at the process states, connect and rpcreconnect, seem to suggest
something involving yp/nis or NFS or some such.

try: ls -n (skip uid to symbolic name lookup) and see if it behaves any
differently