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 10-15 arquivos e diretórios em /var/www . Principalmente apenas arquivos de texto. Aqui estão algumas informações investigativas:
[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 de conclusão de tabulação de todos os arquivos / diretórios será bem-sucedida:
[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 enforcamento:
[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 nos processos, mesmo como sudo.
O que mais devo fazer para investigar esse problema? Apenas começou a acontecer aleatoriamente hoje.
ATUALIZAÇÃO
dmesg é uma lista grande de coisas, principalmente relacionadas a um HDD USB externo que eu montei muitas vezes e a contagem máxima de montagens foi alcançada, mas eu acho que é um problema não relacionado. Perto da parte inferior de 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/ apresenta todo um BUNCH de informações. Eu 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) = ?
Execute o strace ls /var/www/ e veja o que ele trava. É certamente pendurado em E / S - é o que significa o estado D em sua ps output (e como kill não ajuda, é um dos syscalls de E / S ininterruptas). A maioria dos travamentos envolve um servidor NFS que é dedicado a Deus, mas baseado no seu df que não é o caso aqui. Uma verificação rápida de dmesg para qualquer coisa relacionada a sistemas de arquivos ou discos pode valer a pena, apenas no caso.
Eu tive um problema com os mesmos sintomas. Descobri que eu tinha um link simbólico nesse diretório para uma montagem SMB sobre o GVFS.
lrwxrwxrwx 1 alex alex 45 Sep 16 2011 foo -> /home/alex/.gvfs/bar on foo/data/
Normalmente, ls seria concluído instantaneamente se o compartilhamento foi montado ou não. Mas nesse caso eu havia suspendido e retomou a máquina, e a montaria estava tendo um desempenho ruim em geral. Remontar o compartilhamento corrigiu o problema.
Eu estava passando pelo mesmo problema.
Entrar em um diretório é bom, listá-lo trava, encontrar trabalhos, trava completa de abas e algumas pastas abaixo do funcionam. Muito cabeça-arranhando-estranho.
A leitura deste thread no Server Fault levou-me a um caminho lógico em direção à solução.
O fato de ser NAS e NAS ser comumente usado como 'automount' me fez perceber que recentemente eu mudei meu fstab para 'automontar' algumas unidades USB se elas estivessem presentes, mas continuem normais quando não estavam .
Eu então procedi da seguinte forma:
Tente entrar no diretório novamente e tenha a sensação de ter resolvido o problema.
Eu tive os mesmos sintomas exatos que você descreveu. Para corrigir o problema, tudo o que eu precisava fazer era consertar os endereços dos servidores DNS. Nós mudamos o NAS para uma nova rede, o que exigia a atualização dos endereços dos servidores DNS. Os endereços foram atribuídos estatisticamente, mas na interface da web da QNAP eu os atualizei para atribuir automaticamente.
As sugestões da Womble são excelentes, e você deve tentar primeiro, mas se elas não consertarem, eu tive esse problema quando um sistema de arquivos se tornou auto-inconsistente (através de hardware fragmentado, bugs de kernel obscuros ou até mesmo raios cósmicos) .
Se você acha que pode ser isso, você pode forçar um fsck a reinicializar fazendo touch /forcefsck; reboot . Veja o que ele diz no momento da inicialização, para ver se o fsck detecta inconsistências.
Aviso : isso irá fsck todos os sistemas de arquivos anexados à máquina; não faça isso se você também tiver uma matriz de disco com vários petabytes anexada, isso pode levar dias . fsck ing sistemas de arquivos também podem levar à perda de dados; Se você realmente tem inconsistências em seu sistema de arquivos, o e2fsck irá mudá-lo de um que parece certo, mas não funciona bem, para um que funcione direito, mas que não contenha tudo o que você espera.
Na esperança de que isso seja útil, os sintomas acima foram causados usando docker e docker compose com o driver AUFS no Ubuntu 14.04. ls <dir> estava em suspensão e strace ls <dir> mostrou que estava pendurado na chamada getdents . Parar todos os contêineres em execução permitiu que eu começasse a usar a unidade conforme o esperado.
A faixa de execução ls / var / www / lhe dará o que está errado. Eu tive problema semelhante para / dir e usando strace eu era capaz de localizar foi uma montagem NAS que causou isso. Desmontar esse NAS resolveu o problema.