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

32voto

Ryan Sampson Points 2898

Exécutez strace ls /var/www/ et voyez sur quoi ça bloque. C'est certainement bloqué sur l'I/O -- c'est ce que signifie l'état D dans votre sortie ps (et comme kill ne résout pas le problème, il s'agit probablement d'un des appels système d'I/O non interruptibles). La plupart des blocages sont dus à un serveur NFS qui est en panne, mais d'après votre df, ce n'est pas le cas ici. Un check rapide de dmesg pour tout ce qui concerne les systèmes de fichiers ou les disques pourrait être utile, juste au cas où.

5voto

Jeremy Points 4188

En espérant que cela sera utile, j'ai constaté que les symptômes ci-dessus étaient causés par l'utilisation de docker et docker compose avec le pilote AUFS dans Ubuntu 14.04. ls

restait bloqué, et strace ls

montrait qu'il restait bloqué sur l'appel à getdents. Arrêter tous les conteneurs en cours d'exécution m'a permis de commencer à utiliser le lecteur comme prévu.

3voto

SeanO Points 911

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 via GVFS.

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

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

3voto

Aethalides Points 129

J'ai rencontré le même problème.

Entrer dans un répertoire est bien, l'afficher bloque, la fonction 'find' fonctionne, l'auto-complétion bloque, et certains dossiers en dessous fonctionnent. Vraiment étrange à se gratter la tête.

Lire ce fil de discussion sur Server Fault m'a dirigé vers une solution logique.

Le fait que cela concerne un NAS, et que les NAS soient couramment mis en tant que `automount' m'a fait réaliser que j'avais récemment changé mon fstab pour 'automount' certains disques USB s'ils étaient présents mais de continuer normalement s'ils ne l'étaient pas.

J'ai ensuite procédé comme suit:

  1. Démonter la partition contenant le répertoire délinquant.
  2. Modifier le fstab et convertir tous les 'automount' en soit commenté soit sans auto.
  3. Recharger SystemD si vous l'avez: systemctl --system daemon-reload
  4. mount -a

Essayez à nouveau d'entrer dans le répertoire et ressentez cette chaleur agréable d'avoir résolu le problème.

2voto

jamesdlin Points 113

Cela m'est arrivé. La cause était finalement due à un point de montage sshfs dans le répertoire où le serveur SSH était devenu injoignable. strace ne m'a donné aucun indice que ls était bloqué sur cette entrée (ou peut-être que je ne sais pas comment lire la sortie de strace).

J'ai réussi à identifier la cause en :

  • Remarquant que mon alias habituel ls bloquait mais que l'exécution directe de /bin/ls ne bloquait pas.
  • J'ai ensuite pu subdiviser la liste des répertoires de manière itérative avec différentes expressions globales pour trouver quelle entrée posait problème. Par exemple :

    $ ls -d [a-lA-L]* # OK
    $ ls -d [m-zM-Z]* # Bloque
    $ ls -d [m-sM-S]* # Bloque
    ...

Curieusement, dans mon cas, /bin/ls -F fonctionnait mais /bin/ls --color ne fonctionnait pas. (Je ne comprends pas pourquoi, mais cela mérite probablement sa propre question.)

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