umount Dispositivo ou recurso ocupado; ja tentei: mount, lsof, fuser, exportfs, ps axf

Question

Como parte de um sistema de criação de VM automatizado, um dispositivo de bloco é montado em uma pasta temporária (/ tmp / whatever). Vários scripts instalam e configuram a VM antes de sua primeira execução.

Recentemente, algo mudou, a montagem temporária está ocupada e se recusa a desmontar. Ao tentar determinar o que ainda pode manter um arquivo aberto, verifiquei:

Os testes são executados como raiz

• monte
• lsof | grep / tmp /
• fuser -m / tmp /...
• exportfs -rv
• Reiniciando o daemon que executa os scripts de criação de qualquer maneira ...
• ps axf
• tabela dmsetup
• losetup -a
• fuser -vm /tmp/tmp.random-chars/ (produz duas linhas)
• • COMANDO DE ACESSO PID DO USUÁRIO
• • /tmp/tmp.random-chars: montagem do kernel raiz /tmp/tmp.random-chars

Nenhum dos testes acima tem resultados que apontam para o uso do sistema de arquivos, no entanto umount -f ainda reclama "Dispositivo ou recurso ocupado" / "dispositivo está ocupado".

Que outros testes devo tentar para que eu possa obter a causa raiz verdadeira e, assim, consertar a montagem presa sem reinicializar em um sistema que não posso reiniciar por um tempo, bem como evitar que isso ocorra novamente?

Também é / duvidoso / (mas não sei como verificar) que os módulos do kernel da montagem temporária estão carregados, já que a montagem temporária possui uma versão diferente do Linux instalada do que o host está sendo executado.

edições

• De vários resultados de pesquisa, parece que / modules / são simplesmente lidos na memória. Eu não sei se o kernel pode ter arquivos abertos e como acessar qualquer lista.
• Adicionamos o dmsetup / losetup às listas de "testes que não mostram problemas"
• fuser -vm como sugerido no freenode ## linux

Answer 1

Se for parte de um processo de criação, suponho que você precisará reinicializar em algum momento. Tente inserir uma desmontagem "lenta" no processo. Use umount -l /tmp e veja se isso ajuda você a superar essa barreira no processo.

    

Answer 2

Nós temos o mesmo problema, mas parece que só acontece se o sistema de arquivos raiz da máquina virtual for ext4. ext3 funciona corretamente. Eu sei que parece estranho, mas pode ser um bug do kernel descrito no link

Se for assim, devemos simplesmente aguardar o patch do kernel OU evitar a instalação da nova vm na máquina principal. Instalá-lo a partir de uma execução temporária do linux, pois a máquina virtual funciona corretamente porque a máquina é reinicializada sem reinicializar a máquina principal.

Você tentou o ext3? Se não, tente instalar no ext3, você pode convertê-lo para ext4 mais tarde se usar o ext4 for crucial (e é descrito em link )

    

Answer 3

Um motivo umount pode falhar é se o endereço IP subjacente do dispositivo remoto foi alterado.

Eu vi isso acontecer quando montei um laptop remotamente do meu servidor de desktop. A primeira montagem ocorre com o endereço IP A. Embora a reinicialização do laptop forneça o endereço B, minha área de trabalho continua a registrar o endereço A como o endereço do laptop. Posso ver isso quando examino o endereço IP retornado pelo comando mount e o comparo com o endereço atual do laptop.

• Eu consegui desmontar usando umount -l
• A solução para este problema foi - para mim - usar um endereço IP fixo para o laptop