ls se cuelga para un determinado directorio

Hay un directorio particular ( /var/www), que cuando ejecuto ls(con o sin algunas opciones), el comando se cuelga y nunca se completa. Solo hay unos 10-15 archivos y directorios en /var/www. Principalmente solo archivos de texto. Aquí hay información de investigación:

[me@server www]$ df .
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_dev-lv_root
                       50G   19G   29G  40% /

[me@server www]$ df -i .
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/vg_dev-lv_root
                        3.2M    435K    2.8M   14% /

findfunciona bien. También puedo escribir cd /var/www/y presionar TAB antes de presionar enter y con éxito completará la lista de todos los archivos / directorios allí:

[me@server www]$ cd /var/www/
cgi-bin/         create_vhost.sh  html/            manual/          phpMyAdmin/      scripts/         usage/
conf/            error/           icons/           mediawiki/       rackspace        sqlbuddy/        vhosts/
[me@server www]$ cd /var/www/

He tenido que matar mis sesiones de terminal varias veces debido al lsbloqueo:

[me@server ~]$ ps | grep ls
gdm       6215  0.0  0.0 488152  2488 ?        S<sl Jan18   0:00 /usr/bin/pulseaudio --start --log-target=syslog
root     23269  0.0  0.0 117724  1088 ?        D    18:24   0:00 ls -Fh --color=always -l
root     23477  0.0  0.0 117724  1088 ?        D    18:34   0:00 ls -Fh --color=always -l
root     23579  0.0  0.0 115592   820 ?        D    18:36   0:00 ls -Fh --color=always
root     23634  0.0  0.0 115592   816 ?        D    18:38   0:00 ls -Fh --color=always
root     23740  0.0  0.0 117724  1088 ?        D    18:40   0:00 ls -Fh --color=always -l
me       23770  0.0  0.0 103156   816 pts/6    S+   18:41   0:00 grep ls

kill no parece tener ningún efecto en los procesos, incluso como sudo.

¿Qué más debo hacer para investigar este problema? Hoy comenzó a suceder al azar.

ACTUALIZAR

dmesges una gran lista de cosas, principalmente relacionadas con un disco duro USB externo que he montado demasiadas veces y se ha alcanzado el conteo máximo de montaje, pero creo que ese es un problema no relacionado. Cerca del final de esto dmesgestoy viendo esto:

INFO: task ls:23579 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ls            D ffff88041fc230c0     0 23579  23505 0x00000080
 ffff8801688a1bb8 0000000000000086 0000000000000000 ffffffff8119d279
 ffff880406d0ea20 ffff88007e2c2268 ffff880071fe80c8 00000003ae82967a
 ffff880407169ad8 ffff8801688a1fd8 0000000000010518 ffff880407169ad8
Call Trace:
 [<ffffffff8119d279>] ? __find_get_block+0xa9/0x200
 [<ffffffff814c97ae>] __mutex_lock_slowpath+0x13e/0x180
 [<ffffffff814c964b>] mutex_lock+0x2b/0x50
 [<ffffffff8117a4d3>] do_lookup+0xd3/0x220
 [<ffffffff8117b145>] __link_path_walk+0x6f5/0x1040
 [<ffffffff8117a47d>] ? do_lookup+0x7d/0x220
 [<ffffffff8117bd1a>] path_walk+0x6a/0xe0
 [<ffffffff8117beeb>] do_path_lookup+0x5b/0xa0
 [<ffffffff8117cb57>] user_path_at+0x57/0xa0
 [<ffffffff81178986>] ? generic_readlink+0x76/0xc0
 [<ffffffff8117cb62>] ? user_path_at+0x62/0xa0
 [<ffffffff81171d3c>] vfs_fstatat+0x3c/0x80
 [<ffffffff81258ae5>] ? _atomic_dec_and_lock+0x55/0x80
 [<ffffffff81171eab>] vfs_stat+0x1b/0x20
 [<ffffffff81171ed4>] sys_newstat+0x24/0x50
 [<ffffffff810d40a2>] ? audit_syscall_entry+0x272/0x2a0
 [<ffffffff81013172>] system_call_fastpath+0x16/0x1b

Y también, strace ls /var/www/escupe un montón de información. No sé lo que es útil aquí ... El último puñado de líneas:

ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=68, ws_col=145, ws_xpixel=0, ws_ypixel=0}) = 0
stat("/var/www/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/var/www/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fcntl(3, F_GETFD)                       = 0x1 (flags FD_CLOEXEC)
getdents(3, /* 16 entries */, 32768)    = 488
getdents(3, /* 0 entries */, 32768)     = 0
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 9), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3093b18000
write(1, "cgi-bin  conf  create_vhost.sh\te"..., 125cgi-bin  conf  create_vhost.sh      error  html  icons  manual  mediawiki  phpMyAdmin  rackspace  scripts  sqlbuddy  usage   vhosts
) = 125
close(1)                                = 0
munmap(0x7f3093b18000, 4096)            = 0
close(2)                                = 0
exit_group(0)                           = ?

Corre strace ls /var/www/y mira a qué se aferra. Ciertamente está colgado en E / S, eso es lo que significa el Destado en su pssalida (y como killno ayuda, es una de las llamadas de sistema de E / S ininterrumpibles). La mayoría de los bloqueos involucran un servidor NFS que se ha ido a Dios, pero en base a dfeso ese no es el caso aquí. Una revisión rápida de dmesgcualquier cosa relacionada con sistemas de archivos o discos puede valer la pena, por si acaso.

Tuve un problema con los mismos síntomas. Resultó que tenía un enlace simbólico en ese directorio a un montaje SMB sobre GVFS.

lrwxrwxrwx  1 alex alex        45 Sep 16  2011 foo -> /home/alex/.gvfs/bar on foo/data/

Normalmente lsse completaría instantáneamente si el recurso compartido estaba montado o no. Pero en este caso había suspendido y reanudado la máquina, y el montaje estaba funcionando mal en general. Remontar el recurso reparó el problema.

Estaba experimentando el mismo problema.

Entrando en un directorio está bien, lista que se cuelga, encontrar trabajos, pestaña se cuelga completos, y algunas carpetas debajo do trabajo. Muy raramente rasposo.

Leer este hilo en Server Fault me ​​llevó a una ruta lógica hacia la solución.

Tiene que ver con NAS, y el NAS que comúnmente se pone como 'montaje automático' me hizo darme cuenta de que recientemente había cambiado mi fstab a 'montaje automático' de algunas unidades usb si estaban presentes, pero continúan como siempre cuando no lo estaban.

Luego procedí de la siguiente manera:

1. Desmonte la partición que contiene el directorio delincuente.
2. Edite fstab y convierta todo el montaje automático en comentado o sin automático.
3. Vuelva a cargar SystemD si lo tiene: systemctl --system daemon-reload
4. monte -a

Intente ingresar al directorio nuevamente y obtenga esa cálida sensación borrosa de haber solucionado el problema.

Las sugerencias de Womble son excelentes, y debería probarlas primero, pero si no lo solucionan, he tenido este problema cuando un sistema de archivos se ha vuelto inconsistente (a través de hardware escamoso, errores oscuros del núcleo o incluso rayos cósmicos).

Si crees que podría ser eso, puedes forzar un reinicio fsck haciendo touch /forcefsck; reboot. Mire lo que dice en el momento del arranque, para ver si el fsck detecta alguna inconsistencia.

Advertencia : esto fsck todos los sistemas de archivos conectados a la máquina; no lo haga si también tiene una matriz de discos de múltiples petabytes conectada, puede llevar días . fscking sistemas de archivos también puede conducir a la pérdida de datos; Si realmente tiene inconsistencias en su sistema de archivos, e2fsck lo cambiará de uno que se ve bien pero no funciona bien, a uno que funcione bien pero que no contenga todo lo que espera.

Tuve los mismos síntomas exactos que describiste. Para solucionar el problema, todo lo que tenía que hacer era arreglar las direcciones del servidor DNS. Habíamos trasladado el NAS a una nueva red, lo que requería actualizar las direcciones del servidor DNS. Las direcciones se asignaron estáticamente, pero en la interfaz web de QNAP la actualicé para asignar automáticamente.

Con la esperanza de que esto sea útil, tuve los síntomas anteriores causados ​​por el uso dockery docker composecon el controlador AUFS en Ubuntu 14.04. ls <dir>estaba colgando, y strace ls <dir>mostró que estaba colgando en la getdentsllamada. Detener todos los contenedores en ejecución me permitió comenzar a usar la unidad como se esperaba.

Ejecutar strace ls / var / www / le informará de lo que está mal. Tuve un problema similar para / dir y usando strace pude localizarlo fue un montaje NAS que lo causó. Desmontar ese NAS solucionó el problema.