ls se bloque pour un certain répertoire
Il existe un répertoire particulier (/var/www), que lorsque j'exécute ls (avec ou sans certaines options), la commande se bloque et ne se termine jamais. Il n'y a que 10 à 15 fichiers et répertoires dans /var/www. Principalement des fichiers texte. Voici quelques informations d'enquête:
[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% /
find fonctionne très bien. Je peux également taper cd /var/www/ et appuyez sur la touche TAB avant d'appuyer sur entrée et la liste de tous les fichiers/répertoires y parviendra avec succès:
[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 du blocage de ls:
[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 comme Sudo.
Que dois-je faire d'autre pour étudier ce problème? Cela a commencé au hasard aujourd'hui.
MISE À JOUR
dmesg est une grande liste de choses, principalement liées à un disque dur USB externe que j'ai monté trop de fois et le nombre de montage maximum a été atteint, mais c'est un problème sans rapport avec moi. Près du bas de dmesg je 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) = ?
Courir strace ls /var/www/ et voyez de quoi il s'agit. Il est certainement accroché aux E/S - c'est ce que l'état D dans votre sortie ps signifie (et puisque kill n'aide pas, c'est l'un des E/S sans interruption O syscalls). La plupart des blocages impliquent un serveur NFS qui est allé à Dieu, mais basé sur votre df ce n'est pas le cas ici. Une vérification rapide de dmesg pour tout ce qui concerne les systèmes de fichiers ou les disques peut être utile, 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 SMB montage sur GVFS.
lrwxrwxrwx 1 alex alex 45 Sep 16 2011 foo -> /home/alex/.gvfs/bar on foo/data/
Normalement, ls se termine instantanément, que le partage soit 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.
Entrer dans un répertoire est très bien, le lister se bloque, trouver des travaux, se bloquer complètement et certains dossiers sous faire fonctionnent. Très bizarre.
La lecture de ce fil sur Server Fault m'a conduit sur un chemin logique vers la solution.
Cela a à voir avec le NAS, et NAS couramment utilisé comme `automount 'm'a fait réaliser que j'avais récemment changé mon fstab en' automount 'certains lecteurs USB s'ils étaient présents mais continuent comme normal quand ils ne l'étaient pas.
J'ai ensuite procédé comme suit:
- Démontez la partition contenant le répertoire délinquant.
- Modifiez fstab et convertissez tous les montages automatiques en commentaires ou sans auto.
- Rechargez SystemD si vous l'avez: systemctl --system daemon-reload
- monter -a
Essayez d'entrer à nouveau dans le répertoire et obtenez cette sensation floue chaleureuse d'avoir résolu le problème.
Les suggestions de Womble sont excellentes, et vous devriez les essayer en premier, mais si elles ne le résolvent pas, j'ai eu ce problème lorsqu'un système de fichiers est devenu incohérent (grâce à du matériel feuilleté, des bugs obscurs du noyau ou même des rayons cosmiques).
Si vous pensez que cela pourrait être le cas, vous pouvez forcer un fsck au redémarrage en faisant touch /forcefsck; reboot. Regardez ce qu'il dit au démarrage, pour voir si le fsck détecte des incohérences.
Attention: cela fsck tous les systèmes de fichiers attachés à la machine; ne le faites pas si vous disposez également d'une matrice de disques de plusieurs pétaoctets, cela peut prendre jours . fscking les 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 à celui qui fonctionne correctement mais peut ne pas contenir tout ce que vous attendez.
J'ai eu les mêmes symptômes exacts que vous avez décrits. Pour résoudre le problème, tout ce que j'avais à faire était de corriger les adresses des serveurs DNS. Nous avions déplacé le NAS vers un nouveau réseau, ce qui nécessitait la mise à jour des adresses de serveur DNS. Les adresses étaient statiquement attribuées, mais dans l'interface Web QNAP, je les ai mises à jour pour les attribuer automatiquement.
Dans l'espoir que cela sera utile, j'ai eu les symptômes ci-dessus causés par l'utilisation de docker et docker compose avec le pilote AUFS dans Ubuntu 14.04. ls <dir> était suspendu et strace ls <dir> a montré qu'il était suspendu à l'appel getdents. L'arrêt de tous les conteneurs en cours d'exécution m'a permis de commencer à utiliser le lecteur comme prévu.