Eu tenho uma unidade de ataque montada aqui:
/data/
E determinados diretórios como este:
/data/somedir/somesubdir/
quando eu corro
ls
w / ou w / o qualquer sinalizadores, o terminal não retorna nada. Não retorna uma listagem de diretórios vazia. Ele simplesmente vai para a próxima linha e fica em branco sem nenhum aviso. Eu não posso sair do CTRL-C. Eu tenho que fechar esta instância do terminal e começar de novo.
No começo eu pensei que era algo a ver com o comando ls, mas está apontando para / bin / ls e eu consigo ls outros diretórios bem.
Além disso, executando este
find /data/somedir/somesubdir
encontra imediatamente todos os arquivos como esperado.
ATUALIZAÇÃO:
O dmesg não parece estar cuspindo nenhum erro que eu veja. Meu ataque está em / dev / sda5 então se eu fizer
dmesg | grep sda
Eu obtenho
sd 0:0:0:0: [sda] 1953083392 512-byte hardware sectors (999979 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: disabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 1953083392 512-byte hardware sectors (999979 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: disabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3 sda4 <<7>libata version 2.21 loaded.
sda5 >
sd 0:0:0:0: [sda] Attached SCSI disk
EXT3 FS on sda3, internal journal
EXT3 FS on sda5, internal journal
EXT3 FS on sda2, internal journal
EXT3 FS on sda1, internal journal
Nada fora do comum.
Além disso, meu controlador de raids 3ware mostra todos os discos como status OK e não mostra nenhum relatório de nenhum problema com eles.
Não parece haver nenhum comprometimento do servidor.
Além disso:
ps auxww | grep somesubdir
retorna apenas o processo do grep para esse diretório.
ATUALIZAÇÃO # 2:
Eu tentei deixar o comando por mais de uma hora e nenhum resultado. Eu estava com uma perda para o que fazer a seguir, então fui em frente e reiniciei o servidor. O problema não persiste mais, embora demore cerca de 10 segundos para obter uma listagem de diretórios nesse subdiretório. Eu não tenho ideia do problema antes.
Além das sugestões acima, também vi esse problema quando há um grande número de arquivos no diretório que você está listando, o que pode fazer com que o sistema de arquivos fique sem inodes. Se isso for uma possibilidade, tente apenas deixar o comando ls para ver se ele é concluído após algum tempo.
Seus discos provavelmente estão com problemas. Você poderia tentar isso:
Terminal 1$ ls /data/somedir/somesubdir/
(hang)
Terminal 2$ ps auxww | grep somesubdir
Se o status do seu ls for D , isso significa que ele está aguardando o disco fazer alguma coisa. Procure em dmesg por mensagens de status e procure na SMART, se ainda não estiver usando, para ver como esses discos são saudáveis.
Por que o find funciona bem? Porque não faz um stat() em cada arquivo. Isso indica que o diretório está ok, mas um ou mais arquivos estão em uma seção danificada do disco (ou algo similar).
ls sem nenhum sinalizador retornará nada se o diretório estiver vazio. Você precisa de pelo menos ls -a se quiser ver alguma coisa no caso de o diretório estar vazio.
Se o diretório não estiver vazio, é possível que você tenha um sistema de arquivos corrompido - execute o fsck para verificar. Se o sistema de arquivos estiver correto e o diretório não estiver vazio, a próxima pergunta é a questão ls - talvez sua cópia do ls tenha sido substituída em uma forma muito primitiva de rootkit?
Tente descobrir onde ele está pendurado, executando
strace ls $DIR
Talvez exista um arquivo com um nome, que contém uma sequência de bytes que bloqueiam seu terminal. Às vezes, você pode desbloquear um terminal bloqueado enviando Ctrl-Q atalho de teclado ( Ctrl-S bloqueia).
Tente fazer /bin/ls -N | less -S e verifique se há algum nome de arquivo com caracteres suspeitos ou de controle. Menos mostraria esses caracteres como códigos hexadecimais em colchetes angulares, por exemplo <BF> .
A existência de um arquivo com caracteres com um código menor que 32 (de <01> a <1F> ) pode ser um sinal de comprometimento do sistema. Ou um bug de gerenciamento de memória em algum programa que cria arquivos lá.