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

Às vezes, eu gostaria de desmontar um dispositivo USB com umount /run/media/theDrive, mas eu recebo um drive is busyerro.

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

Use lsof | grep /media/whateverpara descobrir o que está usando o suporte.

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

Na maioria das vezes, o melhor comando para uso é lsof ( “ l i s t o pen f iles”).

lsof +f -- /media/usb0

onde /media/usb0é o ponto de montagem da unidade USB ou outro sistema de arquivos para desmontar. +f --diz ao lsof para tratar o argumento subsequente como um ponto de montagem; geralmente, mas nem sempre, gerencia por conta própria, o que lsof /media/usb0também funciona. Ele encontra arquivos abertos (mesmo os não vinculados), 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 existem unidades onde lsofdeve ser executado como root).

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

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

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

fuser -m /media/usb0

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

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

Abrir arquivos

Processos com arquivos abertos são os culpados de sempre. Mostre-os:

lsof +f -- <mountpoint or device>

Há uma vantagem em usar, em /dev/<device>vez de /mountpoint: um ponto de montagem desaparece após um umount -lou pode ser oculto por um suporte sobreposto.

fusertambém pode ser usado, mas na minha opinião lsoftem 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 sua vida.

Liste os arquivos <mountpoint>(veja a advertência acima):

fuser -vmM <mountpoint>

Interativamente, mate apenas processos com arquivos abertos para gravação:

fuser -vmMkiw <mountpoint>

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

fuser -vmMk <mountpoint>

Pontos de montagem

O culpado pode ser o próprio kernel. Outro sistema de arquivos montado no sistema de arquivos que você está tentando umountcausar luto. Verificar 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 ( opencom O_TMPFILE)
• inotify relógios
• [eventfd]
• [eventpoll]
• [timerfd]

Estes são o tipo mais evasivo de pokemon, e aparecem em lsof's TYPEcoluna como a_inode(o que não é documentado na lsofpágina do manual ).

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

lsof | grep a_inode

Para processos de eliminação que contêm inodes anônimos, consulte: Listar os relógios atuais para identificação (nome do caminho, PID) .

inotify relógios (Linux)

Este comentário explica porque inotify não deve impedir um desmontar, mas esta nota descreve as situações em que vontade :

uma desmontagem pode travar na vx_softcnt_flush()chamada. O travamento ocorre porque os relógios inotify incrementam a i_countvariável e fazem com que o valor v_os_hold valuepermaneça elevado até que o observador inotify libere a retenção.

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

Para (pelo menos) OpenBSD:

$ fstat /mnt/mountpoint

Por exemplo (usar doaspara executar fstatcomo root, caso contrário, veríamos apenas 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, não seria possível desmontar /usr/portsaté o usuário _pbuildconcluir a execução desses dois makeprocessos.

Essa é uma armadilha comum: você faz uso de um usuário diferente (root 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 saiu desse diretório, pode tentar encontrar até ficar cego. lsofmostra ao shell qual diretório atual está usando esse dispositivo. Você pode querer su como esse usuário novamente para alterar seu diretório.