51 votes

Ls reste en attente pour un certain répertoire

Il y a un répertoire particulier (/var/www), qui lorsque j'exécute ls (avec ou sans options), la commande se bloque et ne se termine jamais. Il y a seulement environ 10 à 15 fichiers et répertoires dans /var/www. Principalement des fichiers texte. Voici quelques informations d'investigation :

[me@server www]$ df .
Système de fichiers      Taille Utilisé Disponible Uti% Monté sur
/dev/mapper/vg_dev-lv_root
                       50G   19G   29G  40% /

[me@server www]$ df -i .
Système de fichiers      Inodes   IUtilisés   ILibres IUtil% Monté sur
/dev/mapper/vg_dev-lv_root
                        3,2 M    435 K    2,8 M   14% /

find fonctionne bien. Je peux également taper cd /var/www/ et appuyer sur TAB avant d'appuyer sur entrée et il affichera avec succès la liste complète des fichiers/répertoires qui s'y trouvent :

[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 terminal à cause de ls qui se bloque :

[me@server ~]$ ps | grep ls
gdm       6215  0.0  0.0 488152  2488 ?        S

`kill` ne semble avoir aucun effet sur les processus, même en tant que sudo.

Que devrais-je faire d'autre pour investiguer ce problème ? Il a commencé à se produire aléatoirement aujourd'hui.

MISE À JOUR

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

INFO: la tâche ls:23579 est bloquée depuis plus de 120 secondes.
"L'echo 0 > /proc/sys/kernel/hung_task_timeout_secs" désactive ce message.
ls            D ffff88041fc230c0     0 23579  23505 0x00000080
 ffff8801688a1bb8 0000000000000086 0000000000000000 ffffffff8119d279
 ffff880406d0ea20 ffff88007e2c2268 ffff880071fe80c8 00000003ae82967a
 ffff880407169ad8 ffff8801688a1fd8 0000000000010518 ffff880407169ad8
Call Trace:
 [] ? __find_get_block+0xa9/0x200
 [] __mutex_lock_slowpath+0x13e/0x180
 [] mutex_lock+0x2b/0x50
 [] do_lookup+0xd3/0x220
 [] __link_path_walk+0x6f5/0x1040
 [] ? do_lookup+0x7d/0x220
 [] path_walk+0x6a/0xe0
 [] do_path_lookup+0x5b/0xa0
 [] user_path_at+0x57/0xa0
 [] ? generic_readlink+0x76/0xc0
 [] ? user_path_at+0x62/0xa0
 [] vfs_fstatat+0x3c/0x80
 [] ? _atomic_dec_and_lock+0x55/0x80
 [] vfs_stat+0x1b/0x20
 [] sys_newstat+0x24/0x50
 [] ? audit_syscall_entry+0x272/0x2a0
 [] system_call_fastpath+0x16/0x1b

Et aussi, strace ls /var/www/ affiche une TONNE d'informations. Je ne sais pas ce qui est utile ici... Les dernières 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)                           = ?``

1voto

MadHatter Points 77602

Les suggestions de Womble sont excellentes, et vous devriez d'abord les essayer, mais si elles ne corrigent pas le problème, j'ai rencontré ce problème lorsque le système de fichiers est devenu auto-incohérent (à travers du matériel défaillant, des bugs de noyau obscurs, ou même des rayons cosmiques).

Si vous pensez que c'est peut-être ça, 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 va fsck tous les systèmes de fichiers attachés à la machine; ne le faites pas si vous avez également un array de disques multi-petabytes attaché, cela peut prendre des jours. Faire un fsck sur les systèmes de fichiers peut également entraîner une perte de données; si vous avez vraiment des incohérences dans votre système de fichiers, e2fsck le changera d'un aspect correct mais qui ne fonctionne pas tout à fait, à un aspect correct mais qui peut ne pas contenir tout ce que vous attendez.

1voto

todd Points 31

J'ai eu exactement les mêmes symptômes que vous avez décrits. Pour résoudre le problème, il me suffisait de corriger les adresses du serveur DNS. Nous avions déplacé le NAS vers un nouveau réseau, ce qui nécessitait la mise à jour des adresses du serveur DNS. Les adresses étaient assignées statiquement, mais dans l'interface web de QNAP, je les ai mises à jour pour les assigner automatiquement.

-2voto

Shan Navas J Points 9

Exécuter strace ls /var/www/ vous donnera une idée de ce qui ne va pas. J'ai eu un problème similaire pour le répertoire / et en utilisant strace j'ai pu localiser que c'était un montage NAS qui en était la cause. Démonter ce NAS a résolu le problème.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X