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% /
find
funciona 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 ls
travamento:
[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) = ?
Respostas:
Corra
strace ls /var/www/
e veja o que ele aguenta. Certamente depende da E / S - é isso que significa oD
estado na suaps
saída (e, comokill
nã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 seudf
não é o caso aqui. Uma verificação rápida dedmesg
qualquer coisa relacionada a sistemas de arquivos ou discos pode valer a pena, apenas por precaução.fonte
ls
for aliasado a algo que tenta desreferenciar links simbólicos para encontrar o que eles apontam, pode ser suspenso se o link simbólico apontar para uma montagem NFS inoperante.df .
e não um cheiodf
. Definitivamente, poderia ser um problema do NFS.strace ls /var/www/
imprime um monte de coisas. O que procuro? A última linha éexit_group(0) = ?
.strace -vf ls -l /var/www
ver se ele pára em um arquivo ou diretório específico.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.
Normalmente
ls
seria 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.fonte
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:
Tente entrar no diretório novamente e tenha a sensação de ter resolvido o problema.
fonte
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 .
fsck
sistemas 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.fonte
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.
fonte
Na esperança de que isso seja útil, tive os sintomas acima causados pelo uso
docker
edocker compose
com o driver AUFS no Ubuntu 14.04.ls <dir>
estava pendurado estrace ls <dir>
mostrou que estava pendurado nagetdents
chamada. A interrupção de todos os contêineres em execução me permitiu começar a usar a unidade conforme o esperado.fonte
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.
fonte