umount: o dispositivo está ocupado. Por quê?

Ao executar umount /path, recebo:

umount: /path: device is busy.

O sistema de arquivos é enorme, portanto lsof +D /pathnão é uma opção realista.

lsof /path,, lsof +f -- /pathe fuser /pathtodos não retornam nada. fuser -v /pathdá:

                  USER        PID ACCESS COMMAND
/path:            root     kernel mount /path

o que é normal para todos os sistemas de arquivos montados não utilizados.

umount -le umount -fnão é bom o suficiente para a minha situação.

Como faço para descobrir por que o kernel acha que esse sistema de arquivos está ocupado?

Parece que a causa do meu problema foi a nfs-kernel-serverexportação do diretório. O nfs-kernel-serverprovavelmente vai atrás das arquivos abertos normais e, portanto, não está listado por lsofe fuser.

Quando parei o diretório, nfs-kernel-serverpude umount.

Fiz uma página com exemplos de todas as soluções até agora aqui: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

Para adicionar BruceCran do comentário acima, o motivo de minha manifestação deste problema agora era um velho montagem de auto-retorno. Eu já havia verificado a saída de fuser -vm <mountpoint>/ lsof +D <mountpoint>, mounte cat /proc/mountsverificado se algum servidor antigo do nfs-kernel estava em execução, desativado cotas, tentado (mas falhado) umount -f <mountpoint>e quase me resignado a abandonar o tempo de atividade de 924 dias antes de finalmente verificar a saída de losetupe encontrando dois envelhecer loopbacks configurado-but-não-montados:

parsley:/mnt# cat /proc/mounts 
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
/dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user 0 0

então

parsley:/mnt# fuser -vm /mnt/big/
parsley:/mnt# lsof +D big
parsley:/mnt# umount -f /mnt/big/
umount2: Device or resource busy
umount: /mnt/big: device is busy
umount2: Device or resource busy
umount: /mnt/big: device is busy

parsley:/mnt# losetup -a    
/dev/loop0: [fd02]:59 (/mnt/big/dot-dropbox.ext2)
/dev/loop1: [fd02]:59 (/mnt/big/dot-dropbox.ext2)

parsley:/mnt# losetup -d /dev/loop0
parsley:/mnt# losetup -d /dev/loop1
parsley:/mnt# losetup -a
parsley:/mnt# umount big/
parsley:/mnt#

Uma postagem no fórum do Gentoo também lista os arquivos de troca como um possível culpado; embora a troca para arquivos seja provavelmente muito rara atualmente, não custa nada verificar a saída de cat /proc/swaps. Não tenho certeza se as cotas poderiam impedir uma desmontagem - eu estava agarrando canudos.

Em vez de usar lsof para rastrear o sistema de arquivos, use a lista total de arquivos abertos e faça o grep. Acho que esse retorno deve ser mais rápido, embora seja menos preciso. Deve fazer o trabalho.

lsof | grep '/path'

Para mim, o processo ofensivo foi um daemon rodando em um chroot. Porque estava em um chroot, lsofe fusernão o encontraria.

Se você suspeitar que ainda tem algo em execução em um chroot, sudo ls -l /proc/*/root | grep chrootencontrará o culpado (substitua "chroot" pelo caminho para o chroot).

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>

Interaja apenas com processos abertos 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, 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) .

Para que o fusor relate os PIDs que mantêm uma montagem aberta, é necessário usar -m

fuser -m /path

Temos um sistema proprietário em que o sistema de arquivos raiz normalmente é somente leitura. Ocasionalmente, quando os arquivos precisam ser copiados, é remontado para leitura e gravação:

mount -oremount,rw /

E depois remontou de volta:

mount -oremount,ro /

Desta vez, no entanto, mountcontinuou dando o mount: / is busyerro. Isso foi causado por um processo que mantinha um descritor aberto em um arquivo que havia sido substituído por algum comando, que foi executado quando o sistema de arquivos foi lido / gravado. A linha importante da lsof -- /saída é (os nomes foram alterados):

replicate  1719 admin DEL REG 8,5  204394 /opt/gns/lib/replicate/modules/md_es.so

Observe o DELna saída. Simplesmente reiniciar o processo segurando o arquivo excluído resolveu o problema.

lsofe fusertambém não me deu nada.

Após um processo de renomear todos os diretórios possíveis para .old e reiniciar o sistema todas as vezes que fiz alterações, encontrei um diretório específico (relacionado ao postfix) responsável.

Aconteceu que uma vez eu fiz um link simbólico de /var/spool/postfixpara /disk2/pers/mail/postfix/varspoolpara minimizar gravações de disco em um sistema de arquivos raiz baseado em SDCARD (Sheeva Plug).

Com este link simbólico, mesmo depois de parar o postfixe dovecotserviços (tanto ps auxassim como netstat -tuanpnão mostra nada relacionado) não foi capaz de unmount /disk2/pers.

Quando removi o link simbólico e atualizei os arquivos postfixe dovecotconfig para apontar diretamente para os novos diretórios, /disk2/pers/consegui parar com êxito os serviços e unmounto diretório.

Na próxima vez, examinarei mais atentamente a saída de:

ls -lR /var | grep ^l | grep disk2

O comando acima listará recursivamente todos os links simbólicos em uma árvore de diretórios (aqui começando em /var) e filtrará os nomes que apontam para um ponto de montagem de destino específico (aqui disco2).

Eu tive esse problema e, no fundo, havia sessões de tela ativas que eu desconhecia. Eu me conectei à outra sessão de tela ativa e seu shell ainda não estava no diretório montado. Matar essas outras sessões de shell corrigiu o problema para mim.

Apenas pensei em compartilhar minha resolução.

Hoje o problema era um soquete aberto (especificamente tmux):

mount /mnt/disk
export TMPDIR=/mnt/disk
tmux
<<detatch>>
umount /mnt/disk
umount: /mnt/disk: device is busy.
lsof | grep /mnt/disk
tmux      20885             root    6u     unix 0xffff880022346300        0t0    3215201 /mnt/disk/tmux-0/default

Eu tenho um par de binde overlaymonta sob o meu monte que estava me bloqueando, verifique a conclusão da aba para a montagem de ponto que você deseja desmontar. Eu suspeito que foi a montagem de sobreposição em particular, mas poderia ter sido também os vínculos

Isso é mais uma solução alternativa do que uma resposta, mas estou publicando para o caso de ajudar alguém.

No meu caso, eu estava tentando modificar o LVM, pois queria aumentar a partição / var, por isso precisava desmontá-la. Eu tentei todos os comentários e respondi neste post (obrigado a todos e principalmente ao @ ole-tange por reuni-los) e ainda recebi o erro "o dispositivo está ocupado".

Também tentei matar a maioria dos processos na ordem especificada no nível de execução 0, caso a ordem fosse relevante no meu caso, mas isso também não ajudou. Então, o que fiz foi criar um nível de execução personalizado (combinando a saída do chkconfig em novos comandos chkconfig --level) que seria muito semelhante ao 1 (modo de usuário único), mas com recursos de rede (com rede ssh e xinet).

Como eu estava usando o redhat, o nível de execução 4 está marcado como "não utilizado / definido pelo usuário", então usei esse e execute init 4 No meu caso, estava tudo bem, pois eu precisava reiniciar o servidor em qualquer caso, mas provavelmente será esse o caso de alguém mexendo nos discos.