Linux: qué proceso está causando & # 8220; dispositivo ocupado & # 8221; cuando haces umount? [cerrado]
Pregunta
Linux: el proceso que está causando " dispositivo ocupado " cuando haces umount?
Solución
Mire el comando lsof (enumere los archivos abiertos): puede indicarle Qué procesos mantienen lo abierto. A veces es complicado pero a menudo algo tan simple como sudo lsof | grep (el nombre de tu dispositivo aquí)
podría hacerlo por ti.
Otros consejos
Por si acaso ... a veces sucede que está llamando umount desde el terminal, y su directorio actual pertenece al sistema de archivos montado.
Debería usar el comando fuser .
Por ej. fuser / dev / cdrom
devolverá los pid (s) del proceso utilizando / dev / cdrom
.
Si está intentando desmontar, puede finalizar este proceso con el interruptor -k
(consulte man fuser
).
Compruebe si hay dispositivos de bucle abierto asignados a un archivo en el sistema de archivos con " losetup -a " ;. No se mostrarán ni con lsof ni con el fusor.
Verifique también / 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
.
lsof +f -- /mountpoint
(como enumera los procesos que usan archivos en el montaje montado en / mountpoint. Particularmente útil para encontrar qué procesos están utilizando una memoria USB o CD / DVD montado.
lsof y fuser son, de hecho, dos formas de encontrar el proceso que mantiene abierto un determinado archivo. Si solo quieres que umount tenga éxito, debes investigar sus opciones -f y -l.
Es exactamente por eso que " fuser -m / mount / point " existe.
Por cierto, no creo que " fusor " o " lsof " indicará cuándo un recurso está en poder del módulo del kernel, aunque normalmente no tengo ese problema ...
Lsof y fuser tampoco me dieron nada.
Después de un proceso 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 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).
Abrir archivos
Los procesos con archivos abiertos son los culpables habituales. Mostrarlos:
lsof +f -- <mountpoint or device>
Hay una ventaja al 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
, pero para mí, lsof
tiene un resultado más útil. Sin embargo, fuser
es útil cuando se trata de acabar con los procesos que causan sus dramas para que pueda seguir con su vida.
Listar archivos en < mountpoint >
(vea la advertencia más arriba):
fuser -vmM <mountpoint>
Mata 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 núcleo mismo. Otro sistema de archivos montado en el sistema de archivos que está intentando umount
causará dolor. Consulte con:
mount | grep <mountpoint>/
Para montajes de bucle invertido, también verifique la salida de:
losetup -la
Inodes anónimos (Linux)
Inodes anónimos pueden ser creados por:
- Archivos temporales (
abierto
conO_TMPFILE
) - inotify relojes
- [eventfd]
- [eventpoll]
- [timerfd]
Este es el tipo de Pokémon más esquivo y aparece en la columna lsof
de TYPE
como a_inode
(que no está documentado en el < a href = "http://man7.org/linux/man-pages/man8/lsof.8.html" rel = "nofollow noreferrer"> 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: Enumere los relojes inotify actuales (nombre de ruta, PID) .
Si aún no puede desmontar o volver a montar su dispositivo después de detener todos los servicios y procesos con archivos abiertos, es posible que haya 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 la unidad systemd . 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, para poder 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.
sistemas de archivos montados en el sistema de archivos que está intentando desmontar pueden hacer que el error target is busy
, además de los archivos que están en uso. (Por ejemplo, cuando monte -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'