ls trava para um determinado diretório

Há um diretório específico ( /var/www), que quando executo ls(com ou sem algumas opções), o comando trava e nunca é concluído. Existem apenas cerca de 10 a 15 arquivos e diretórios no /var/www. Principalmente apenas arquivos de texto. Aqui estão algumas informações de investigação:

[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 bem. Também posso digitar cd /var/www/e pressionar TAB antes de pressionar enter e a lista com todos os arquivos / diretórios será concluída com sucesso:

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

Eu tive que matar minhas sessões de terminal várias vezes por causa do lstravamento:

[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 parece não ter nenhum efeito sobre os processos, mesmo que sudo.

O que mais devo fazer para investigar esse problema? Isso começou aleatoriamente a acontecer hoje.

ATUALIZAR

dmesgé uma grande lista de coisas, principalmente relacionadas a um HDD USB externo que montei muitas vezes e a contagem máxima de montagens foi atingida, mas acho que esse é um problema não relacionado. Perto do fundo dmesg, estou vendo isso:

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

E também, strace ls /var/www/cospe um monte de informações. Não sei o que é útil aqui ... O último punhado de linhas:

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

Corra strace ls /var/www/e veja o que ele aguenta. Certamente depende da E / S - é isso que significa o Destado na sua pssaída (e, como killnão ajuda, é um dos chamados ininterruptos de E / S). A maioria dos travamentos envolve um servidor NFS que foi para Deus, mas com base no seu dfnão é o caso aqui. Uma verificação rápida de dmesgqualquer coisa relacionada a sistemas de arquivos ou discos pode valer a pena, apenas por precaução.

Eu tive um problema com os mesmos sintomas. Aconteceu que eu tinha um link simbólico nesse diretório para uma montagem SMB sobre GVFS.

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

Normalmente lsseria concluído instantaneamente, independentemente de o compartilhamento ter sido montado. Mas, nesse caso, suspendi e reiniciei a máquina, e a montagem estava com um desempenho ruim em geral. Remontar o compartilhamento corrigiu o problema.

Eu estava com o mesmo problema.

Entrando em um diretório é bom, listando ele trava, encontrar obras, aba trava completas, e algumas pastas debaixo fazer o trabalho. Muito cabeça-arranhando-estranho.

A leitura deste tópico na falha do servidor me levou a um caminho lógico em direção à solução.

Isso tem a ver com o NAS, e o NAS geralmente sendo colocado como `` automount '' me fez perceber que recentemente havia mudado meu fstab para 'automount' algumas unidades USB se elas estivessem presentes, mas continuassem normalmente quando não estavam.

Eu procedi da seguinte maneira:

1. Desmonte a partição que contém o diretório delinquente.
2. Edite o fstab e converta todo o automount em comentado ou sem auto.
3. Recarregue o SystemD se você o tiver: systemctl --system daemon-reload
4. montar -a

Tente entrar no diretório novamente e tenha a sensação de ter resolvido o problema.

As sugestões de Womble são excelentes, e você deve experimentá-las primeiro, mas se elas não resolverem, eu tive esse problema quando um sistema de arquivos se tornou inconsistente (através de hardware escamoso, bugs obscuros do kernel ou mesmo raios cósmicos).

Se você acha que pode ser isso, você pode forçar um fsck na reinicialização fazendo isso touch /forcefsck; reboot. Veja o que diz no momento da inicialização, para ver se o fsck capta alguma inconsistência.

Aviso : isto irá fsck todos os sistemas de arquivos conectados à máquina; não faça isso se você também tiver uma matriz de discos com vários petabytes, pode levar dias . fscksistemas de arquivos também podem levar à perda de dados; se você realmente tiver inconsistências no seu sistema de arquivos, o e2fsck mudará de um que parece certo, mas não funciona, para um que funciona corretamente, mas pode não conter tudo o que você espera.

Eu tive os mesmos sintomas exatos que você descreveu. Para corrigir o problema, tudo o que eu precisava fazer era corrigir os endereços do servidor DNS. Mudamos o NAS para uma nova rede, o que exigia a atualização dos endereços do servidor DNS. Os endereços foram atribuídos estaticamente, mas na interface da Web da QNAP, eu o atualizei para atribuir automaticamente.

Na esperança de que isso seja útil, tive os sintomas acima causados ​​pelo uso dockere docker composecom o driver AUFS no Ubuntu 14.04. ls <dir>estava pendurado e strace ls <dir>mostrou que estava pendurado na getdentschamada. A interrupção de todos os contêineres em execução me permitiu começar a usar a unidade conforme o esperado.

Executar strace ls / var / www / mostrará o que está errado. Eu tive um problema semelhante para / dir e, usando o strace, consegui localizá-lo como uma montagem NAS que o causou. A desmontagem desse NAS corrigiu o problema.