ls se bloque pour un certain répertoire

Il y a un répertoire particulier ( /var/www), que lorsque je lance ls(avec ou sans certaines options), la commande se bloque et ne se termine jamais. Il n’ya qu’environ 10-15 fichiers et répertoires dans /var/www. Principalement juste des fichiers texte. Voici quelques informations d'investigation:

[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% /

findfonctionne bien. Aussi, je peux taper cd /var/www/et appuyer sur la touche de tabulation avant d'appuyer sur Entrée. La liste complète de tous les fichiers / répertoires qui y figurent se trouve alors:

[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/

J'ai dû tuer plusieurs fois mes sessions de terminal à cause de la lspendaison:

[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 ne semble pas avoir d'effet sur les processus, même en tant que sudo.

Que dois-je faire pour enquêter sur ce problème? Cela a juste commencé au hasard aujourd'hui.

MISE À JOUR

dmesgest une grande liste de choses, principalement liées à un disque dur USB externe que j'ai monté trop de fois et le nombre de montages maximum a été atteint, mais c'est un problème non lié, je pense. Au bas de la page, dmesgje vois ceci:

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

Et aussi, strace ls /var/www/crache tout un tas d'informations. Je ne sais pas ce qui est utile ici ... La dernière poignée de lignes:

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)                           = ?

Courez strace ls /var/www/et voyez à quoi il se bloque. Il est certainement bloqué sur les E / S - c'est ce que signifie l' Détat de votre pssortie (et comme cela killn'aide pas, c'est l'un des appels système ininterruptibles d'E / S). La plupart des blocages impliquent un serveur NFS qui est allé à Dieu, mais basé sur votre dfce n'est pas le cas ici. Une vérification rapide de dmesgtout ce qui concerne les systèmes de fichiers ou les disques pourrait en valoir la peine, au cas où.

J'ai eu un problème avec les mêmes symptômes. Il s'est avéré que j'avais un lien symbolique dans ce répertoire vers un montage SMB sur GVFS.

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

Normalement ls, compléterait instantanément si le partage était monté ou non. Mais dans ce cas, j'avais suspendu et repris la machine, et la monture fonctionnait mal en général. Remonter le partage a résolu le problème.

Je rencontrais le même problème.

La saisie d' un répertoire est très bien, la liste il se bloque, trouver des œuvres, onglet se bloque complets, et certains dossiers sous do travail. Très bizarre.

La lecture de ce fil sur Server Fault m'a conduit sur un chemin logique vers la solution.

Il s’agissait de NAS, et le fait que NAS soit couramment appelé «automount» m’a fait comprendre que j’avais récemment changé mon fstab en «automount» de certains lecteurs USB, s’ils étaient présents, mais que les choses se déroulaient normalement.

J'ai alors procédé comme suit:

1. Démontez la partition contenant le répertoire en souffrance.
2. Editez fstab et convertissez tous les montages automatiques en commentaires ou sans auto.
3. Rechargez SystemD si vous en avez un: systemctl --system daemon-reload
4. monte -a

Essayez d'entrer à nouveau dans le répertoire et obtenez ce sentiment de flou chaleureux d'avoir résolu le problème.

Les suggestions de Womble sont excellentes, et vous devriez les essayer en premier, mais s’ils ne le corrigent pas, j’ai eu ce problème quand un système de fichiers est devenu inconsistant (à travers un matériel floconneux, des bugs obscurs du noyau, voire des rayons cosmiques).

Si vous pensez que cela pourrait être le cas, vous pouvez forcer un fsck au redémarrage en le faisant touch /forcefsck; reboot. Regardez ce qu'il dit au démarrage, pour voir si le fsck détecte des incohérences.

Attention : cela va fsck tous les systèmes de fichiers attachés à la machine; ne le faites pas si vous avez également un ensemble de disques de plusieurs pétaoctets connecté, cela peut prendre des jours . fsckLes systèmes de fichiers peuvent également entraîner une perte de données; si vous avez vraiment des incohérences dans votre système de fichiers, e2fsck le changera, de celui qui semble correct mais ne fonctionne pas tout à fait, de celui qui fonctionne correctement mais ne contient pas tout ce que vous attendez.

J'ai eu exactement les mêmes symptômes que vous avez décrits. Pour résoudre le problème, tout ce que je devais faire était de réparer les adresses du serveur DNS. Nous avions déplacé le NAS sur un nouveau réseau, ce qui nécessitait la mise à jour des adresses de serveur DNS. Les adresses ont été attribuées de manière statique, mais dans l'interface Web de QNAP, je l'ai mis à jour pour l'attribuer automatiquement.

Sur l'espoir que ce sera utile, j'ai eu les symptômes ci - dessus étant causés par l' utilisation dockeret docker composeavec le pilote AUFS dans Ubuntu 14.04. ls <dir>était suspendu et a strace ls <dir>montré qu'il était suspendu à l' getdentsappel. L'arrêt de tous les conteneurs en cours d'exécution m'a permis de commencer à utiliser le lecteur comme prévu.

Lancer strace ls / var / www / vous donnera une idée de ce qui ne va pas. J'ai eu un problème similaire pour / dir et en utilisant strace, j'ai pu localiser le montage du NAS. Le démontage de ce NAS a résolu le problème.