Está demorando muito tempo em um pequeno diretório

Executando o Ubuntu, abro um terminal e faço

sudo bash
cd /
ls | head -n 1000

E previsivelmente cerca de 20 diretórios são retornados.

No entanto, se eu fizer um sl, e não o colocar em nada, o sl apenas fica lá até eu o matar em outro terminal. O que poderia estar acontecendo?

EDITAR:

> type ls
ls is aliased to `ls --color=auto`

EDITAR:

> /bin/ls /
<normal response>
> /bin/ls --color=auto
<hangs indefinitely>

Por que colorir a saída de ls está causando a interrupção desse comando?

— Snitse
fonte

Execute type lspara verificar possíveis aliases etc.

— jw013 29/03

A execução strace lspode potencialmente ajudar a identificar o problema. straceexibe todas as chamadas do sistema feitas pelo programa que ele chama.

— Gowtham

Tente /bin/ls(ou melhor, command ls) executar lssem as opções com alias, para confirmar se é ou não a opção de cor que está fazendo a diferença. FWIW, lsdesativa a coloração quando sua saída é um tubo ou outro dispositivo não terminal.

— Jw013 29/03/2012

uma barra invertida antes de um comando executá-lo, em vez do alias também. \ls

— Rob

Se você executar ls normalmente, ele mostrará apenas a lista de arquivos sem a necessidade de executar o stat (2) em nenhum deles. Em outras palavras, ele não acessa os próprios arquivos, mas apenas o diretório que contém os arquivos.

Se você adicionar a opção --color ou usar outras opções ls que precisam examinar os arquivos, então ls precisará declarar (2) esses arquivos.

Provavelmente, pelo menos um dos arquivos em seu diretório está realmente sendo montado em um sistema remoto, via NFS ou similar. E o servidor do qual você montou essa partição não está ativo ou não está respondendo. Portanto, quando o ls tenta obter as informações sobre esse diretório, ele fica travado no kernel, aguardando a resposta do servidor.

Como outros já mencionaram, se você usar o strace, descobrirá qual diretório o ls está tentando acessar quando trava. Então você pode desmontar a partição montada ou o que for.

— Cientista maluco
fonte

Outra possibilidade é que um dos arquivos em seu diretório seja um link simbólico apontando para alguma partição remota e cujo servidor não esteja respondendo ... mesmo princípio.

— MadScientist 29/03

Eu tinha NFS montado a partir de um servidor que estava fora do ar. Parece estranho que o stat apenas fique pendurado no suporte do nfs. Não seria muito difícil dizer se estava inoperante e apenas imprima o diretório na cor em que os links simbólicos quebrados são impressos.

— Snitse

Na verdade, é difícil (para ls) dizer que o servidor NFS está inoperante. NFS é apenas um tipo diferente de sistema de arquivos (como ext3, xfs, etc.) Todos os sistemas de arquivos são implementados no kernel. Um programa de usuário como ls (1) simplesmente executa uma chamada de sistema como stat (2) em um nome de caminho; não tem idéia de que tipo de sistema de arquivos está sendo usado. Nesse caso, a chamada do sistema trava (portanto, o aplicativo userspace fica travado) até que o resultado seja obtido. Então, ls é adormecido pelo kernel até que o resultado seja obtido ... o que nunca acontece. Então, não posso dizer que algo está errado.

— Cientista louco

Devo dizer que você pode mudar o comportamento do NFS. Se você especificar uma "montagem rígida", o kernel tentará se reconectar sempre que o servidor atingir o tempo limite e não retornará da chamada de sistema até que isso aconteça. Como alternativa, você pode solicitar uma "montagem suave", onde o kernel retornará com uma falha se o pedido do servidor atingir o tempo limite. No entanto, muitos / a maioria dos programas não são gravados para lidar adequadamente com esses tipos de operações de tempo limite e, portanto, especificar montagens suaves no NFS é perigoso e causa instabilidade no sistema. Quem usa o NFS regularmente quase sempre usa e recomenda montagens rígidas. Veja nfs (5).

— Cientista louco

Eu tinha sshfsmontarias, e a única maneira de desmontá-las era matando os relacionados sshe os sshfsprocessos.

— Gauthier