stdout redirecionar. sh: recurso temporariamente indisponível

3

Eu tenho grandes lotes de processos bash. Cada script bash invoca executáveis que têm seu stdout redirecionado para arquivos de log distintos. Cerca de 5% das corridas acabam com: sh: [nome do log]: Recurso temporariamente indisponível Tentei reduzir a quantidade de tarefas em execução em paralelo, mas ainda assim o erro persistiu em alguns dos scripts bash.

Informações adicionais:

  • Ubuntu 14.04 LTS em execução na VM usando o ESXi
  • Acontece em uma nova partição, alocada com o gparted e o LVM (novo volume lógico que consiste na partição inteira)
  • O LV é exportado usando o nfs-kernel-server
  • O LV também é compartilhado no windows usando o Samba
  • O LV é formatado usando o ext4
  • Eu tenho direitos de administrador nesta máquina

Informações mais detalhadas

  • Tudo é executado em um cluster, usando o Sun-Grid-Engine
  • Existem 4 máquinas virtuais: m1, m2, m3, m4
  • m1 executa sge master, sge exec e ldap server
  • m2, m3, m4 executa sge exec
  • m3 executa o nfs-kernel-server, exportando uma pasta home localizada em volume lógico (usando LVM) que usa uma partição em um disco local, para m1, m2, m4
  • m3 tem um link para a pasta home
  • m1, m2, m4 monte a pasta home através do fstab, para que todas as máquinas apontem para a mesma pasta home
  • m3, m2, m4 executam clientes ldap, conectando-se a m1
  • Todas as tarefas são enviadas ao cluster por meio de m1 (configurado como um host de envio)
  • Trabalhos falham exclusivamente no m3 (que exporta o disco). A maioria dos trabalhos em m3 está passando embora. As falhas são aleatórias, mas consistentemente no m3 sozinho.
  • m3 também compartilha o home via samba para clientes Windows

Qualquer ajuda seria muito apreciada :) (como depurar, quais logs são relevantes, como obter mais informações do sistema, etc ...)

Obrigado antecipadamente!

    
por lev haikin 31.12.2014 / 08:47

1 resposta

0

Obrigado a todos que tentaram ajudar!

O problema foi resolvido montando o volume lógico em m3 usando nfs exatamente da mesma maneira que as outras máquinas m1 / m2 / m4 que são clientes nfs, em vez de ter um link flexível em m3 para o volume lógico. Basta adicionar a seguinte linha ao / etc / fstab: <nfs server>:/ /mnt nfs auto 0 0 e depois invocar sudo mount -a .

A dica estava no fato de que as falhas estavam acontecendo consistentemente no m3, que é o servidor nfs, e o reenvio automático de trabalhos com falha resolveu o problema também. Nunca houve falhas em m1 / m2 / m4 (que são os clientes da nfs). Lembre-se de que m3 é o servidor nfs, que possui um link simples para o volume lógico, enquanto todos os clientes usam o nfs para conectar esse volume lógico.

No fundo da minha cabeça eu tive a sensação de que provavelmente o nfs protege seus clientes de terem esses problemas, mas eu pensei que o sistema de arquivos no volume lógico não deveria falhar, e se isso acontecer, então eu tenho um problema real que eu devo raiz causa. Este pode ser o caso ainda.

Se você tiver insights sobre o problema e a solução, escreva. Não quero mascarar problemas se forem reais.

    
por 05.01.2015 / 10:56