it-swarm.dev

Linux: ¿Qué proceso está causando "dispositivo ocupado" al realizar el desmontaje?

Linux: ¿Qué proceso está causando "dispositivo ocupado" al realizar el desmontaje?

68
flybywire

Mire el comando lsof (listar archivos abiertos) - puede decirle qué procesos están manteniendo abierto. A veces es complicado, pero a menudo algo tan simple como Sudo lsof | grep (your device name here) podría hacerlo por ti.

96
MarkusQ

Por si acaso ... a veces sucede que está llamando umount desde el terminal, y su directorio actual pertenece al sistema de archivos montado.

41
alvatar

Debe utilizar el comando fuser.

P.ej. fuser /dev/cdrom devolverá los pid (s) del proceso usando /dev/cdrom.

Si está intentando desmontar, puede detener el proceso de tesis usando el interruptor -k (vea man fuser).

22
Ben

Verifique si hay dispositivos de bucle abierto asignados a un archivo en el sistema de archivos con "losetup -a". No aparecerán ni con lsof ni con el fusor.

18
Jay

También verifique /etc/exports. Si está exportando rutas dentro del punto de montaje a través de NFS, dará este error cuando intente desmontar y no aparecerá nada en fuser o lsof.

15
Malvineous
lsof +f -- /mountpoint

(como enumera los procesos que usan archivos en el montaje montado en/mountpoint. Particularmente útil para encontrar qué procesos están usando una memoria USB montada o un CD/DVD.

9
mas

de hecho, lsof y fuser son dos formas de encontrar el proceso que mantiene abierto un determinado archivo. Si solo desea que umount tenga éxito, debe investigar sus opciones -f y -l.

7
Anonymous

Es exactamente por eso que existe el "fusor -m/mount/point".

Por cierto, no creo que "fuser" o "lsof" indiquen cuándo un recurso está en poder del módulo del kernel, aunque normalmente no tengo ese problema ...

5
Carter Galle

lsof y fuser tampoco me dieron nada.

Después de cambiar el nombre de todos los directorios posibles a .old y reiniciar el sistema cada vez que hice cambios, encontré un directorio en particular (relacionado con postfix) que era responsable.

Resultó que una vez hice un enlace simbólico de/var/spool/postfix a/disk2/pers/mail/postfix/varspool para minimizar las escrituras en el disco en un sistema de archivos raíz basado en SDCARD (Sheeva Plug).

Con este enlace simbólico, incluso después de detener los servicios postfix y dovecot (tanto ps aux como netstat -tuanp no mostraron nada relacionado) no pude desmontar/disk2/pers.

Cuando quité el enlace simbólico y actualicé los archivos de configuración postfix y dovecot para que apunten directamente a las nuevas direcciones en/disk2/pers /, pude detener los servicios con éxito y desmontar el directorio.

La próxima vez miraré más de cerca la salida de:

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

El comando anterior mostrará una lista recursiva de todos los enlaces simbólicos en un árbol de directorios (comenzando en/var) y filtrará los nombres que apuntan a un punto de montaje de destino específico (aquí disk2).

2
captcha

Si aún no puede desmontar o volver a montar su dispositivo después de detener todos los servicios y procesos con archivos abiertos, entonces puede haber un archivo de intercambio o una partición de intercambio que mantenga su dispositivo ocupado. Esto no aparecerá con fuser o lsof. Desactivar el intercambio con:

Sudo swapoff -a

Puede verificar de antemano y mostrar un resumen de cualquier partición de intercambio o archivos de intercambio con:

swapon -s

o:

cat /proc/swaps

Como alternativa al uso del comando Sudo swapoff -a, también puede desactivar el intercambio al detener un servicio o systemd unit. Por ejemplo:

Sudo systemctl stop dphys-swapfile

o:

Sudo systemctl stop var-swap.swap

En mi caso, fue necesario desactivar el intercambio, además de detener cualquier servicio y proceso con archivos abiertos para escritura, de modo que pudiera volver a montar mi partición raíz como solo lectura para ejecutar fsck en mi partición raíz sin reiniciar. Esto fue necesario en una Raspberry Pi con Raspbian Jessie.

1
Simon Gould

Abrir archivos

Los procesos con archivos abiertos son los culpables habituales. Mostrarlos:

lsof +f -- <mountpoint or device>

Hay una ventaja de usar /dev/<device> en lugar de /mountpoint: un punto de montaje desaparecerá después de un umount -l, o puede estar oculto por un montaje superpuesto.

fuser también se puede usar, pero en mi opinión lsof tiene un resultado más útil. Sin embargo, fuser es útil cuando se trata de matar los procesos que causan sus dramas para que pueda seguir con su vida.

Listar archivos en <mountpoint> (ver advertencia más arriba):

fuser -vmM <mountpoint>

Matar interactivamente solo los procesos con archivos abiertos para escritura:

fuser -vmMkiw <mountpoint>

Después de volver a montar solo lectura (mount -o remount,ro <mountpoint>), es seguro (r) eliminar todos los procesos restantes:

fuser -vmMk <mountpoint>

Puntos de montaje

El culpable puede ser el propio núcleo. Otro sistema de archivos montado en el sistema de archivos que está intentando umount causará dolor. Comprueba con:

mount | grep <mountpoint>/

Para montajes en bucle, también verifique la salida de:

losetup -la

Inodos anónimos (linux)

Inodos anónimos puede ser creado por:

  • Archivos temporales (open con O_TMPFILE)
  • inotify relojes
  • [eventofd]
  • [eventpoll]
  • [timerfd]

Este es el tipo de Pokémon más esquivo y aparece en la columna lsof 's TYPE como a_inode (que no está documentado en lsof man page ).

No aparecerán en lsof +f -- /dev/<device>, por lo que deberá:

lsof | grep a_inode

Para los procesos de eliminación que contienen inodos anónimos, consulte: Listar los relojes inotify actuales (nombre de ruta, PID) .

1
Tom Hale

Los sistemas de archivos montados en el sistema de archivos que está intentando desmontar pueden causar el error target is busy además de cualquier archivo que esté en uso. (Por ejemplo, cuando mount -o bind /dev /mnt/yourmount/dev para usar chroot allí.)

Para encontrar qué sistemas de archivos están montados en el sistema de archivos, ejecute lo siguiente:

mount | grep '/mnt/yourmount'

Para encontrar qué archivos están en uso, los consejos ya sugeridos por otros aquí:

lsof | grep '/mnt/yourmount'

0
Slobodan Pejic