Falha ao listar o conteúdo do diretório: o processo aguarda infinitamente

Question

Eu uso o Linux Mint 13, e às vezes (raramente) eu não consigo listar o conteúdo do meu diretório pessoal. Quando tento fazer isso:

$ cd
$ ls

então, ls apenas espera indefinidamente. O mesmo com qualquer outro aplicativo quando ele tenta ler o conteúdo do diretório: Eu tenho que matar o aplicativo eventualmente.

Eu usei essa distribuição Linux por cerca de um ano, minha máquina normalmente está sempre ativa (24/7), e eu enfrentei esse problema pela primeira vez há algumas semanas. Então, eu apenas tentei fechar todos os aplicativos, isso não ajudou, então eu reiniciei a máquina, e ajudou: o problema estava "consertado".

Hoje enfrentei novamente. Desta vez eu tentei encontrar um pouco mais sobre o motivo: Eu pesquisei lsof , tentei usá-lo, mas ... ele espera indefinidamente, também! Mais, ele aguarda mesmo que eu tente lsof qualquer diretório, não apenas o diretório home. Digamos que $ lsof /path/to/any/file faça com que lsof espere indefinidamente.

Apenas no caso, eu tentei usar lsof na máquina remota via ssh, funciona. Então, parece um problema mais profundo na minha máquina local.

(Eu não vou reiniciar a máquina agora, espero pegar o motivo)

UPD: partes de dmesg output:

Nov 12 14:35:36 dimon-progr kernel: [1305000.288107] INFO: task lsof:32463 blocked for more than 120 seconds.
Nov 12 14:35:36 dimon-progr kernel: [1305000.288112] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 12 14:35:36 dimon-progr kernel: [1305000.288116] lsof            D c1044aa0     0 32463      1 0x00000084
Nov 12 14:35:36 dimon-progr kernel: [1305000.288122]  f10f3dc0 00000086 f10f3d68 c1044aa0 00000001 f3108ca0 c18e43c0 c18e43c0
Nov 12 14:35:36 dimon-progr kernel: [1305000.288132]  eea0a18a 0004a2af f45073c0 ee00a5e0 ed9c25e0 ee00a5e0 f10f3db4 f10f3d84
Nov 12 14:35:36 dimon-progr kernel: [1305000.288141]  c105be37 ee00a5e0 f10f3d9c c105c535 00000296 f10f3d9c f10f3d9c c1027378
Nov 12 14:35:36 dimon-progr kernel: [1305000.288150] Call Trace:
Nov 12 14:35:36 dimon-progr kernel: [1305000.288160]  [<c1044aa0>] ? try_to_wake_up+0x140/0x190
Nov 12 14:35:36 dimon-progr kernel: [1305000.288167]  [<c105be37>] ? recalc_sigpending+0x17/0x40
Nov 12 14:35:36 dimon-progr kernel: [1305000.288172]  [<c105c535>] ? __set_task_blocked+0x35/0x80
Nov 12 14:35:36 dimon-progr kernel: [1305000.288178]  [<c1027378>] ? default_spin_lock_flags+0x8/0x10
Nov 12 14:35:36 dimon-progr kernel: [1305000.288183]  [<c1576d2d>] ? _raw_spin_lock_irqsave+0x2d/0x40
Nov 12 14:35:36 dimon-progr kernel: [1305000.288188]  [<c1575135>] schedule+0x35/0x50
Nov 12 14:35:36 dimon-progr kernel: [1305000.288193]  [<c121755d>] request_wait_answer+0x6d/0x1f0
Nov 12 14:35:36 dimon-progr kernel: [1305000.288198]  [<c106a390>] ? add_wait_queue+0x50/0x50
Nov 12 14:35:36 dimon-progr kernel: [1305000.288203]  [<c1217758>] fuse_request_send+0x78/0xb0
Nov 12 14:35:36 dimon-progr kernel: [1305000.288208]  [<c121bd6c>] fuse_do_getattr+0x12c/0x280
Nov 12 14:35:36 dimon-progr kernel: [1305000.288213]  [<c113d80d>] ? complete_walk+0x7d/0x100
Nov 12 14:35:36 dimon-progr kernel: [1305000.288219]  [<c121c381>] fuse_update_attributes+0x41/0xa0
Nov 12 14:35:36 dimon-progr kernel: [1305000.288224]  [<c121c684>] fuse_getattr+0x44/0x50
Nov 12 14:35:36 dimon-progr kernel: [1305000.288228]  [<c11370e2>] vfs_getattr+0x42/0x70
Nov 12 14:35:36 dimon-progr kernel: [1305000.288233]  [<c121c640>] ? fuse_listxattr+0x130/0x130
Nov 12 14:35:36 dimon-progr kernel: [1305000.288237]  [<c113716c>] vfs_fstatat+0x5c/0x80
Nov 12 14:35:36 dimon-progr kernel: [1305000.288241]  [<c11371e0>] vfs_stat+0x20/0x30
Nov 12 14:35:36 dimon-progr kernel: [1305000.288245]  [<c1137456>] sys_stat64+0x16/0x30
Nov 12 14:35:36 dimon-progr kernel: [1305000.288251]  [<c100ceec>] ? syscall_trace_enter+0x15c/0x170
Nov 12 14:35:36 dimon-progr kernel: [1305000.288256]  [<c1576ed4>] syscall_call+0x7/0xb
Nov 12 14:35:36 dimon-progr kernel: [1305000.288260]  [<c1570000>] ? encode+0x26/0x2b

    

Answer 1

Processa a tentativa de acessar um bloco do sistema de arquivos indefinidamente se o driver do sistema de arquivos nunca responder.

Para um sistema de arquivos que é armazenado em um dispositivo de armazenamento, a principal causa para não responder é que o hardware subjacente não está respondendo ou está com defeito. Isso geralmente produz mensagens copiosas nos logs do kernel (visíveis com dmesg no Linux ou no arquivo de log apropriado, como /var/log/kern.log ) e, eventualmente, causa um tempo limite e um erro de E / S (EIO).

Sistemas de arquivos com suporte de rede podem não responder porque nenhuma resposta do servidor está chegando, o que pode ocorrer porque a rede está inoperante ou a máquina do servidor está inativa ou o programa do servidor não está sendo executado ou configurado corretamente. Dependendo do tipo de sistema de arquivos, do driver e de sua configuração, isso pode resultar em um tempo limite ou em uma espera infinita. O NFS, em particular, é padronizado para uma espera infinita: ele é sem estado (se o servidor ficar inativo no meio de uma operação, a operação pode continuar quando o servidor retornar), então os clientes bloqueiam até que o servidor responda (porque se o servidor não voltar eventualmente, em seguida, o sistema de arquivos irá se comportar corretamente).

Para sistemas de arquivos FUSE, cabe ao programa implementar o sistema de arquivos. O FUSE é muito flexível, pois pode ser implementado por programas arbitrários. O reverso da moeda é que às vezes os sistemas de arquivos FUSE não são muito robustos internamente ou dependem de muitos outros componentes que podem se comportar mal.

Se um sistema de arquivos não estiver respondendo, primeiro verifique que tipo de sistema de arquivos é. No Linux, procure o ponto de montagem em /proc/mounts ; o ponto de montagem é o segundo campo e o tipo de sistema de arquivos é o terceiro campo. Isto diz-lhe onde procurar mais pistas:

• Para sistemas de arquivos em um dispositivo de armazenamento, procure nos logs do kernel.
• Para sistemas de arquivos com suporte de rede, verifique a conectividade de rede e verifique se o servidor está respondendo. Registros relevantes geralmente estão em registros de serviço (por exemplo, /var/log/syslog ou /var/log/daemon.log ou um registro específico do serviço de rede).
• Para sistemas de arquivos FUSE, verifique se o processo está respondendo.

Se você tem processos bloqueados em E / S e desistiu de esperar que o sistema de arquivos retornasse, você pode querer forçar a desmontagem do sistema de arquivos. Se for um sistema de arquivos FUSE, matar o processo que o fornece fará o truque. Para qualquer tipo de sistema de arquivos, no Linux, você pode executar uma “desmontagem lenta” com umount -l : isso desanexa o sistema de arquivos do seu ponto de montagem, mesmo se o driver do sistema de arquivos estiver travado; o motorista continua operando (por exemplo, ele continua se comunicando com o hardware, se é isso que está fazendo).