Ao executar umount /path , obtenho:
umount: /path: device is busy.
O sistema de arquivos é enorme, então lsof +D /path não é uma opção realista.
lsof /path , lsof +f -- /path e fuser /path não retornam nada. fuser -v /path dá:
USER PID ACCESS COMMAND
/path: root kernel mount /path
que é normal para todos os sistemas de arquivos montados não utilizados.
umount -l e umount -f não são bons o suficiente para minha situação.
Como descubro por que o kernel acha que esse sistema de arquivos está ocupado?
Parece que a causa do meu problema foi o nfs-kernel-server estar exportando o diretório. O nfs-kernel-server provavelmente fica atrás dos arquivos abertos normais e, portanto, não está listado por lsof e fuser .
Quando parei o nfs-kernel-server , consegui umount o diretório.
Eu fiz uma página com exemplos de todas as soluções até agora: link
Para adicionar perguntas / 15024 / umount-device-is-busy-why # comment43883_15027 "> comentário acima, a causa da minha manifestação deste problema agora é uma montagem de loopback obsoleto . Eu já havia verificado a saída de fuser -vm <mountpoint> / lsof +D <mountpoint> , mount e cat /proc/mounts , verifiquei se algum servidor nfs-kernel antigo estava em execução, desativei as cotas, tentei (mas falhei) a umount -f <mountpoint> e tudo, mas me resignei a abandonar o tempo de atividade de 924 dias antes de finalmente verificar a saída de losetup e encontrar dois loopbacks configurados mas 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 swapfiles como um potencial culpado; Embora a troca de arquivos provavelmente seja bem rara atualmente, não é difícil verificar a saída de cat /proc/swaps . Não tenho certeza se as cotas poderiam impedir uma desmontagem - eu estava me agarrando a palhas.
Em vez de usar lsof para rastrear o sistema de arquivos, basta usar a lista total de arquivos abertos e adicioná-los. 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 era um daemon rodando em um chroot. Como estava em um chroot, lsof e fuser não o encontrariam.
Se você suspeitar que tem algo deixado em execução em um chroot, sudo ls -l /proc/*/root | grep chroot encontrará o culpado (substitua "chroot" pelo caminho para o chroot).
Para que o fusor relate os PIDs que mantêm uma montagem aberta, você precisa usar -m
fuser -m /path
Temos um sistema proprietário em que o sistema de arquivos raiz é normalmente somente leitura. Ocasionalmente, quando arquivos precisam ser copiados, são remontados como leitura-gravação:
mount -oremount,rw /
E então remontamos:
mount -oremount,ro /
No entanto, desta vez, mount continuou apresentando o erro mount: / is busy . Isso foi causado por um processo que mantinha um descritor aberto em um arquivo que tinha sido substituído por algum comando, que foi executado quando o sistema de arquivos era de leitura-gravação. A linha importante da lsof -- / output é (os nomes foram alterados):
replicate 1719 admin DEL REG 8,5 204394 /opt/gns/lib/replicate/modules/md_es.so
Observe o DEL na saída. Simplesmente reiniciar o processo segurando o arquivo excluído resolveu o problema.
lsof e fuser também não me deram nada.
Após um processo de renomear todos os diretórios possíveis para .old e reinicializar o sistema toda vez que fiz alterações, encontrei um diretório específico (relacionado ao postfix) que era responsável.
Descobri que eu tinha feito um link simbólico de /var/spool/postfix para /disk2/pers/mail/postfix/varspool para minimizar gravações em disco em um sistema de arquivos raiz baseado em SDCARD (Sheeva Plug).
Com este link simbólico, mesmo depois de parar os serviços postfix e dovecot (tanto ps aux como netstat -tuanp não mostraram nada relacionado) não consegui unmount /disk2/pers .
Quando removi o link simbólico e atualizei os arquivos postfix e dovecot config para apontar diretamente para os novos diretórios em /disk2/pers/ , consegui parar os serviços e unmount do diretório.
Na próxima vez, vou olhar mais de perto 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 (começando aqui em /var ) e filtrará os nomes que apontarem para um ponto de montagem de destino específico (aqui disk2).
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>
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, verifique também a saída de:
losetup -la
Inodes anônimos podem ser criados por:
open com O_TMPFILE ) 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) .
Eu tive esse problema, e descobri que havia sessões de tela ativas em segundo plano que eu não conhecia. Eu conectei-me à outra sessão de tela ativa e seu shell nem estava atualmente no diretório montado. Matar essas outras sessões de shell resolveu o problema para mim.
Pensei em compartilhar minha resolução.
Hoje, o problema foi 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 bind e overlay montadas na minha montagem que estavam me bloqueando, verifique a conclusão da tabulação para o ponto de montagem que você deseja desmontar. Eu suspeito que foi a montagem overlay em particular, mas poderia ter sido o binds também
Isso é mais uma solução do que uma resposta, mas estou postando no caso de ajudar alguém.
No meu caso eu estava tentando modificar o LVM como eu queria aumentar a partição / var, então eu precisava desmontá-lo. Eu tentei todos os comentários e respostas neste post (obrigado a todos e especialmente @ ole-tange para reuni-los) e ainda tenho o erro "dispositivo está ocupado".
Eu tentei matar a maioria dos processos na ordem especificada no runlevel 0 também, caso a ordem fosse relevante no meu caso, mas isso não ajudou. Então, o que eu fiz foi criar um runlevel personalizado (combinando a saída de chkconfig em novos comandos chkconfig --level) que seria muito semelhante a 1 (modo de usuário único), mas com recursos de rede (com ssh network e xinet).
Como eu estava usando o redhat, o runlevel 4 é marcado como "não usado / definido pelo usuário", então eu usei esse, e corri %código% No meu caso, tudo correu bem, já que eu precisava reiniciar o servidor em qualquer caso, mas provavelmente esse será o caso de qualquer um que esteja mexendo nos discos.
Tags mount