Como descubro quais processos estão impedindo a desmontagem de um dispositivo?

Question

Por vezes, gostaria de desmontar um dispositivo usb , mas obtenho um erro drive is busy .

Como descubro quais processos ou programas estão acessando o dispositivo?

    

Answer 1

Use lsof | grep /media/whatever para descobrir o que está usando a montagem.

Além disso, considere umount -l (umount lento) para impedir que novos processos usem a unidade enquanto você limpa.

    

Answer 2

Na maioria das vezes, o melhor comando para usar é lsof (“ l i s t o caneta f iles ").

lsof +f -- /media/usb0

onde /media/usb0 é o ponto de montagem da unidade USB ou outro sistema de arquivos a ser desmontado. +f -- diz ao lsof para tratar o argumento subsequente como um ponto de montagem; normalmente, mas nem sempre, gerencia por conta própria, de modo que lsof /media/usb0 também funciona. Isso encontra arquivos abertos (mesmo os desvinculados), arquivos mapeados na memória, diretórios atuais e alguns usos mais obscuros. Você precisará executar o comando como root para obter informações sobre os processos de outros usuários (e acho que há unices em que lsof precisa ser executado como root).

Existem usos que o lsof não encontrará; estes são incomuns em mídia removível. Eles incluem:

• pontos de montagem: não é possível desmontar /foo se /foo/bar for um ponto de montagem.
• montar dispositivos: não é possível desmontar /foo se /foo/bar for um dispositivo de bloco montado ou um arquivo regular montado em loop ou se for a origem de uma montagem de ligação do Linux.
• Exportação do NFS: o lsof não detecta que uma árvore é exportada por um servidor NFS do kernel.

Outro comando que pode ser usado em uma pitada é o fusor, que lista apenas PIDs de processos com arquivos abertos no dispositivo:

fuser -m /media/usb0

    

Answer 3

Você pode usar lsof , como Peter disse, ou se tiver certeza de que quer matar todas essas coisas e desmontá-las, provavelmente poderá fazer algo como:

fuser -Mk /mnt/path
umount /mnt/path

    

Answer 4

Se você usar o GNOME, a desmontagem via Nautilus exibirá uma mensagem informando qual processo ainda está usando a unidade e o arquivo que está sendo usado.

    

Answer 5

Arquivos abertos

Processos com arquivos abertos são os culpados usuais. Exibi-los:

lsof +f -- <mountpoint or device>

Há uma vantagem em usar /dev/<device> em vez de /mountpoint : um ponto de montagem desaparecerá após um umount -l ou pode estar oculto por uma montagem sobreposta.

fuser também pode ser usado, mas em minha opinião lsof tem uma saída mais útil. No entanto, fuser é útil quando se trata de matar os processos que causam seus dramas, para que você possa continuar com sua vida.

Listar arquivos em <mountpoint> (veja a advertência acima):

fuser -vmM <mountpoint>

Mata interativamente apenas os processos com arquivos abertos para gravação:

fuser -vmMkiw <mountpoint>

Após remontar somente leitura ( mount -o remount,ro <mountpoint> ), é seguro (r) matar todos os processos restantes:

fuser -vmMk <mountpoint>

Mountpoints

O culpado pode ser o próprio kernel. Outro sistema de arquivos montado no sistema de arquivos que você está tentando umount causará sofrimento. Verifique com:

mount | grep <mountpoint>/

Para montagens de loopback ( obrigado Stephen Kitt ), verifique também a saída de:

losetup -la

Inodes anônimos (Linux)

Inodes anônimos podem ser criados por:

• Arquivos temporários ( open com O_TMPFILE )
• inotify relógios
• [eventfd]
• [eventpoll]
• [timerfd]

Este é o tipo de pokemon mais evasivo e aparece na coluna lsof do TYPE como a_inode (que não está documentado no lsof man page ).

Eles não aparecerão em lsof +f -- /dev/<device> , então você precisará:

lsof | grep a_inode

Para matar processos que contêm inodes anônimos, consulte: Listar os atuais relógios inotify (nome do caminho, PID) .

inotify watches (Linux)

Este comentário explica por que inotify deveria 't impedir uma desmontagem, mas esta nota descreve as situações em que será :

an unmount can hang in the vx_softcnt_flush() call. The hang occurs because inotify watches increment the i_count variable and cause the v_os_hold value to remain elevated until the inotify watcher releases the hold.

    

Answer 6

Para (pelo menos) OpenBSD:

$ fstat /mnt/mountpoint

Por exemplo (usando doas para executar fstat como root, caso contrário, veríamos nossos próprios processos):

$ doas fstat /usr/ports
USER     CMD          PID   FD MOUNT        INUM MODE         R/W    SZ|DV NAME
_pbuild  make       15172   wd /usr/ports  3923598  drwxrwxr-x     r     1536 /usr/ports/
_pbuild  make       40034   wd /usr/ports  3923598  drwxrwxr-x     r     1536 /usr/ports/

Nesse caso, eu não seria capaz de desmontar /usr/ports até que o usuário _pbuild tenha terminado de executar esses dois make processos.

    

Answer 7

Essa é uma armadilha comum: você su para um usuário diferente (raiz ou qualquer outro usuário), muda para o diretório de um dispositivo montado e efetua logout como esse usuário. Quando você esquece que você saiu naquele diretório, você pode tentar e encontrar até que você esteja cego. lsof mostra o shell que o diretório atual está usando esse dispositivo. Você pode querer su como aquele usuário novamente para mudar seu diretório.