ls se comporta de maneira diferente sob strace

Question

Eu não sei como depurar esta situação:

1) Eu tento executar:

ls /home/user

2) bloqueia e não imprime nada. Suponho que seja porque / home / user contém / home / user / sshfs_files, que é um diretório montado pelo sshfs, mas a rede caiu na minha máquina (a rede está ativa novamente, mas acho que a conexão SSH foi perdida).

3) Como eu queria ter certeza de que o diretório sshfs-mounted foi a causa deste desligamento, eu tentei o mesmo comando sob strace:

strace -o /tmp/log ls /home/user

4) E os ls realmente funcionaram! Então, agora a situação é que funciona sob strace mas bloqueia sozinho.

Como isso é possível? Como explicar essa situação? Como posso ver onde ls bloqueia se não bloquear sob strace?

Obrigado!

    

Answer 1

Como jw13 apontou, isso é quase uma duplicata exata de " estou demorando muito tempo no pequeno diretório " - pelo menos no que diz respeito à explicação. Não deixe de ler os comentários também!

Em resumo, alguns programas populares de linha de comando, como ls , podem operar de maneira diferente quando sua saída não vai diretamente para um terminal. Nesse caso, ls , que provavelmente está com alias para ls --color=auto , tenta detectar o tipo de cada entrada de diretório para fins de coloração. Neste ponto, ele trava, incapaz de executar uma operação stat em seu diretório montado pelo sshfs.

Adicionando a resposta do MadScientist à questão mencionada : Se você está curioso sobre como strace or gdb pode ajudar na depuração do comportamento de ls ', sugiro que você execute algo como

 strace -o /tmp/log ls --color=always /home/user

    

Answer 2

Bem, esse é um comportamento comum para programas sob depuração, e não é realmente evitável. A inicialização de mudanças de variáveis, há mais informações disponíveis, o fluxo do programa é alterado.

Você obtém a fonte de ls e a executa através de um depurador diferente, esperando que mostre o erro, ou tente encontrar uma resposta, uma solução alternativa de outras maneiras.