Dispositivo ocupado em Umount

Geralmente, encontro um problema para desmontar um diretório:

umount / mnt / dir
umount: / mnt / dir: o dispositivo está ocupado

Há muitas razões pelas quais o dispositivo está ocupado. Às vezes, existem processos em execução que têm bloqueios abertos, outras vezes, existem outros diretórios montados em cima /mnt/dir.

Minha pergunta:

Quais são as etapas para verificar por que um diretório não pôde ser desmontado.

Sei que há muitas razões, mas tudo bem se você explicar uma solução específica.

[EDITAR]

[X] executando processos em volumes montados.
[X] outro volume é montado em cima de um volume que queremos desmontar
[_] NFS bloqueia o volume que queremos desmontar

A maneira de verificar é fuser -vm /mnt/dir, que deve ser executada como root. Ele informará quais processos estão acessando o ponto de montagem.

Uma alternativa é lsof /mnt/dir, que mostrará cada arquivo aberto na montagem. Novamente, é melhor executar como root.

Você pode executar qualquer um deles como não raiz, mas a saída será limitada aos seus processos - os de outros usuários simplesmente não serão mostrados silenciosamente, mesmo que impeçam a desmontagem do sistema de arquivos.

Exemplo:

Watt:~# fuser -vm /mnt/Zia/src
                     USER        PID ACCESS COMMAND
/mnt/Zia/src:        root     kernel mount /mnt/Zia/src
                     anthony   24909 ..c.. bash
                     anthony   25041 F.c.. gvim

O campo "acesso" informa como está sendo acessado. Nesse caso, o kernel o usa em forma de montagem (duh, mas desmontar só funcionará com isso). bashpossui-o como o diretório de trabalho atual (terá que ser cdum diretório diferente antes da desmontagem) e o gvim possui o diretório atual e um arquivo aberto (será necessário fechar o gvim).

Watt:~# lsof /mnt/Zia/src
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
bash    24909 anthony  cwd    DIR   0,26    12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim    25041 anthony  cwd    DIR   0,26    12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim    25041 anthony    6u   REG   0,26    16384 3526219 /mnt/Zia/src/perl/.utf8.c.swp (zia.vpn.home:/home/anthony/src)

Nesta saída, você pode ver os diretórios atuais do bash e do gvim (como tipo DIR). Você também pode ver qual arquivo o gvim abriu para gravação.

Como forçar o problema:

fuserpossui uma -kopção que enviará um sinal (padrão SIGKILL:) para cada processo usando a montagem. Essa é uma maneira bastante vigorosa de impedir que a montagem fique ocupada. (E, claro, tenha cuidado com o que você SIGKILL!)

umounttem uma -lopção para executar uma desmontagem lenta. A montagem será removida do espaço para nome do sistema de arquivos (para que você não a veja /mnt/Zia/srcmais no exemplo), mas ela permanecerá montada, para que os programas que a acessem possam continuar a fazê-lo. Quando o último programa acessando ele sai, a desmontagem realmente ocorre.

Há uma causa final corrigível de falha na desmontagem, e esse é um servidor NFS inoperante. Aqui você pode usar umount -f, mas corre o risco de perder dados, se o fizer. (O cliente pode ter gravações em cache que ainda não foram confirmadas pelo servidor e essas gravações serão descartadas. No entanto, os aplicativos já foram informados de que a gravação foi bem-sucedida.)

Você deveria usar:

sudo umount -l <path>

Outro volume é montado em cima de um volume que queremos desmontar:

O mountcomando permite que você saiba todos os volumes montados, se invocados sem argumentos nem opções (exceto -v). Você pode ter uma lista de pontos de montagem ativos adicionando um pouco de perl:

mount | perl -pe 's/.*on (\S+) type.*/\1/'

Depois, basta fazer o grep sobre o ponto de referência do qual você deseja desmontar e você saberá se existem sistemas de arquivos montados sobre este.

mount | perl -pe 's/.*on (\S+) type.*/\1/' | grep '/mnt/dir/'

Então você tem duas soluções . Desmonte os sistemas de arquivos ou mova-os com mount --move olddir newdir(kernel> 2.5.1)

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 causará pesar. 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) .

A questão de como verificar se o NFS acessa um diretório que será desmontado ainda não foi respondida.

O que eu tenho é apenas isso:

Verifique se o nfsd está em execução:

pidof nfsd

Mostrar diretórios montados pelos clientes:

showmount -a

e showmountsem argumentos mostra apenas hosts do cliente, mesmo que estejam offline. Presumo que esse seja um comportamento especial do NFS.

Para mim, o problema era que eu estava logado mais de uma vez (via ssh) e em um dos logins eu estava no prompt de comando em que o pwd estava dentro de uma pasta subordinada ao ponto de montagem.