¿Cómo averiguo qué procesos impiden el desmontaje de un dispositivo?

A veces, me gustaría desmontar un dispositivo USB con umount /run/media/theDrive, pero recibo un drive is busyerror.

¿Cómo averiguo qué procesos o programas están accediendo al dispositivo?

Úselo lsof | grep /media/whateverpara averiguar qué está usando el soporte.

Además, considere umount -l(uzyunt) para evitar que nuevos procesos usen la unidad mientras realiza la limpieza.

La mayoría de las veces, el mejor comando a utilizar es lsof ( “ l i s t o pluma f iles”).

lsof +f -- /media/usb0

¿Dónde /media/usb0está el punto de montaje de la unidad USB u otro sistema de archivos para desmontar? +f --le dice a lsof que trate el argumento posterior como un punto de montaje; por lo general, pero no siempre, se maneja solo, por lo que lsof /media/usb0también funciona. Esto encuentra archivos abiertos (incluso los que no están vinculados), archivos mapeados en memoria, directorios actuales y algunos usos más oscuros. Deberá ejecutar el comando como root para obtener información sobre los procesos de otros usuarios (y creo que hay unices donde lsofdebe ejecutarse como root).

Hay usos que lsof no encontrará; Estos son poco comunes en los medios extraíbles. Incluyen:

• puntos de montaje: no puede desmontar /foosi /foo/bares un punto de montaje.
• dispositivos de montaje: no puede desmontar /foosi /foo/bares un dispositivo de bloque montado o un archivo regular montado en bucle, o si es la fuente de un montaje de enlace de Linux.
• Exportación NFS: lsof no detectará que un árbol sea exportado por un servidor NFS del núcleo.

Otro comando que puede servir en caso de necesidad es el fusor, que solo enumera los PID de los procesos con archivos abiertos en el dispositivo:

fuser -m /media/usb0

Puedes usarlo lsofcomo dijo Peter, o si estás seguro de que solo quieres matar todas esas cosas y desmontarlo, probablemente puedas hacer algo como:

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

Abrir archivos

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

lsof +f -- <mountpoint or device>

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

fuserTambién se puede utilizar, pero en mi opinión lsoftiene una salida más útil. Sin embargo, fuseres útil cuando se trata de matar los procesos que causan tus dramas para que puedas seguir con tu vida.

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

fuser -vmM <mountpoint>

Elimine interactivamente solo 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 núcleo mismo. Otro sistema de archivos montado en el sistema de archivos que está intentando umountcausarle dolor. Verifícalo con:

mount | grep <mountpoint>/

Para montajes de bucle invertido ( gracias Stephen Kitt ), también verifique la salida de:

losetup -la

Inodos anónimos (Linux)

Los inodos anónimos pueden ser creados por:

• Archivos temporales ( opencon O_TMPFILE)
• relojes inotify
• [eventfd]
• [eventpoll]
• [timerfd]

Estos son el tipo de pokemon más difícil de alcanzar, y aparecen en lsofla TYPEcolumna como a_inode(que no está documentada en la lsofpágina del manual ).

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

lsof | grep a_inode

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

inotify relojes (Linux)

Este comentario explica por qué inotify no debe impedir que un desmontaje, pero esta nota se describen las situaciones en las que voluntad :

un desmontaje puede colgar en la vx_softcnt_flush()llamada. El bloqueo ocurre porque los relojes inotify incrementan la i_countvariable y hacen v_os_hold valueque permanezca elevada hasta que el observador inotify suelte la retención.

Si usa GNOME, el desmontaje a través de Nautilus mostrará un mensaje que indica qué proceso todavía está usando la unidad y el archivo que está usando.

Para (al menos) OpenBSD:

$ fstat /mnt/mountpoint

Por ejemplo (usar doaspara ejecutar fstatcomo root ya que de lo contrario solo veríamos nuestros propios procesos):

$ 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/

En este caso, no podría desmontar /usr/portshasta que el usuario _pbuildhaya terminado de ejecutar esos dos makeprocesos.

Este es un escollo común: debe recurrir a un usuario diferente (ya sea root o cualquier otro usuario), cambiar al directorio de un dispositivo montado y luego cerrar sesión como ese usuario. Cuando olvides que te fuiste en ese directorio, puedes intentar encontrarlo hasta que estés ciego. lsofmuestra al shell qué directorio actual está usando ese dispositivo. Es posible que desee su como ese usuario nuevamente para cambiar su directorio.