umount: el dispositivo está ocupado. ¿Por qué?

Cuando corro umount /pathme sale:

umount: /path: device is busy.

El sistema de archivos es enorme, por lsof +D /pathlo que no es una opción realista.

lsof /path, lsof +f -- /pathy fuser /pathtodos no devuelven nada. fuser -v /pathda:

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

que es normal para todos los sistemas de archivos montados no utilizados.

umount -ly umount -fno es lo suficientemente bueno para mi situación.

¿Cómo puedo averiguar por qué el núcleo piensa que este sistema de archivos está ocupado?

Parece que la causa de mi problema fue la nfs-kernel-serverexportación del directorio. El nfs-kernel-serverprobablemente va detrás de los archivos abiertos normales y, por lo tanto, no aparece en la lista por lsofy fuser.

Cuando paré nfs-kernel-serverpude umountel directorio.

He hecho una página con ejemplos de todas las soluciones hasta ahora aquí: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

Para añadir a BruceCran 's comentario anterior, el motivo de mi manifestación de este problema ahora era un rancio montaje de bucle de retorno. Ya verifiqué la salida de fuser -vm <mountpoint>/ lsof +D <mountpoint>, mounty cat /proc/mountsverifiqué si se estaba ejecutando algún antiguo servidor nfs-kernel-server, apagué las cuotas, intenté (pero fallé) ay umount -f <mountpoint>todos pero me resigné a abandonar el tiempo de actividad de 924 días antes de finalmente verificar la salida de losetupy la búsqueda de dos bucles-no-montados configurado, pero rancio:

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

entonces

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#

Una publicación en el foro de Gentoo también enumera los archivos de intercambio como un posible culpable; Aunque el intercambio de archivos es probablemente bastante raro en estos días, no está de más comprobar la salida de cat /proc/swaps. No estoy seguro de si las cuotas podrían evitar un desmontaje: estaba agarrando pajitas.

En lugar de usar lsof para rastrear el sistema de archivos, simplemente use la lista total de archivos abiertos y agréguelo. Creo que este rendimiento debe ser más rápido, aunque es menos preciso. Debería hacer el trabajo.

lsof | grep '/path'

Para mí, el proceso ofensivo fue un demonio corriendo en un chroot. Porque estaba en un chroot, lsofy fuserno lo encontraría.

Si sospecha que le queda algo corriendo en un chroot, sudo ls -l /proc/*/root | grep chrootencontrará al culpable (reemplace "chroot" con el camino al chroot).

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, verifique también 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) .

Para que el fusor informe sobre los PID que sostienen una montura abierta, debe usar -m

fuser -m /path

Tenemos un sistema propietario donde el sistema de archivos raíz es normalmente de solo lectura. Ocasionalmente, cuando los archivos tienen que copiarse, se vuelve a montar lectura-escritura:

mount -oremount,rw /

Y luego volver a montar:

mount -oremount,ro /

Esta vez, sin embargo, mountsiguió dando el mount: / is busyerror. Fue causado por un proceso que contenía un descriptor abierto a un archivo que había sido reemplazado por algún comando, que se ejecutó cuando el sistema de archivos era de lectura y escritura. La línea importante de la lsof -- /salida es (se han cambiado los nombres):

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

Observe el DELen la salida. Simplemente reiniciar el proceso manteniendo el archivo eliminado resolvió el problema.

lsofy fusertampoco me dio nada.

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

Resultó que una vez hice un enlace simbólico de /var/spool/postfixa /disk2/pers/mail/postfix/varspoolpara minimizar las escrituras en 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 postfixy dovecot(tanto ps auxcomo netstat -tuanpno mostraron nada relacionado) no pude unmount /disk2/pers.

Cuando quité el enlace simbólico y actualizó el postfixy dovecotarchivos de configuración para que apunte directamente a los nuevos directorios en /disk2/pers/que fue capaz de detener con éxito los servicios y unmountel directorio.

La próxima vez miraré más de cerca el resultado de:

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

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

Tuve este problema y resultó que había sesiones de pantalla activas en segundo plano que no conocía. Me conecté a la otra sesión de pantalla activa y su shell ni siquiera estaba actualmente en el directorio montado. Matar esas otras sesiones de shell solucionó el problema para mí.

Solo pensé en compartir mi resolución.

Hoy el problema era un zócalo abierto (específicamente 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

Tengo un par de bindy overlayse monta bajo mi montura que me estaban bloqueando, comprobar el tabulador para el punto de montaje que desea desmontar. Sospecho que fue la montura superpuesta en particular, pero también podría haber sido la unión

Esta es más una solución que una respuesta, pero la estoy publicando en caso de que pueda ayudar a alguien.

En mi caso, estaba tratando de modificar el LVM porque quería agrandar la partición / var, así que necesitaba desmontarlo. Probé todos los comentarios y respondí en esta publicación (gracias a todos y especialmente a @ ole-tange por reunirlos) y aún recibí el error "dispositivo está ocupado".

Traté de eliminar la mayoría de los procesos en el orden especificado en el nivel de ejecución 0 también, solo en caso de que el orden fuera relevante en mi caso, pero eso tampoco ayudó. Entonces, lo que hice fue crearme un nivel de ejecución personalizado (combinando la salida de chkconfig en nuevos comandos chkconfig --level) que sería muy similar a 1 (modo de usuario único) pero con capacidades de red (con red ssh y xinet).

Como estaba usando redhat, el nivel de ejecución 4 está marcado como "no utilizado / definido por el usuario", así que usé ese y ejecuté init 4 En mi caso, esto estaba bien, ya que necesitaba reiniciar el servidor en cualquier caso, pero probablemente ese será el caso de cualquiera que haya modificado los discos.