¿Cómo superar el "dispositivo o recurso ocupado"?

229

Traté de rm -rfuna carpeta, y obtuve "dispositivo o recurso ocupado".

En Windows, habría usado LockHunter para resolver esto. ¿Cuál es el equivalente de Linux? (Por favor, dé como respuesta un método simple de "desbloquear esto", y no complete artículos como este . Aunque son útiles, actualmente estoy interesado solo en ASimpleMethodThatWorks ™)

files lock

— ripper234
fuente

55

Gracias, esto fue útil: venía de Linux a Windows, estaba buscando el equivalente de lsof - LockHunter.

— Sonia Hamilton

3

¿Que demonios? Unix no le impide eliminar archivos abiertos como lo hace Windows. Es por eso que puede eliminar todo su sistema ejecutando rm -rf /... felizmente eliminará todos los archivos, incluido / bin / rm.

— psusi

1

@psusi, eso es incorrecto. O tienes una mala fuente de información o simplemente estás inventando cosas. Linux, como Windows, tiene bloqueo de archivos y dispositivos. Sin embargo, está un poco roto. 0pointer.de/blog/projects/locking.html

— foobarbecue

1

@foobarbecue, normalmente son solo bloqueos de aviso y la página de manual al menos parece indicar que son solo para lectura / escritura, no para desvincular.

— psusi

232

La herramienta que desea es lsof, que significa archivos abiertos de lista .

Tiene muchas opciones, así que revisa la página de manual, pero si quieres ver todos los archivos abiertos en un directorio:

lsof +D /path

Eso se repetirá a través del sistema de archivos debajo /path, así que tenga cuidado de hacerlo en grandes árboles de directorios.

Una vez que sepa qué procesos tienen archivos abiertos, puede salir de esas aplicaciones o eliminarlas con el kill(1)comando.

— camh
fuente

46

¿Y si no hubiera resultados?

— infantes de marina

22

@marines: compruebe si hay otro sistema de archivos montado debajo /path. Esa es una causa de los "archivos abiertos" ocultos.

— camh

2

El comando lsof directamente a la ruta no funciona. Entonces, básicamente, debo ir a la ubicación de la ruta y luego ejecutar lsof busy_file y luego matar todo el proceso

— J4cK

44

lsofparece no hacer nada por mí: lsof storage/logs/laravel.logno devolvió nada, y lo mismo hizo lsof +D storage/logs/. umountrespondió con not mounted.

— Ryan

1

Solo para elaborar sobre la respuesta de @camh: Uso mount | grep <path>. Eso muestra que cualquiera /dev/<abc>podría estar montado en el <path>. Use sudo umount -lf /dev/<abc>y luego intente eliminar <path>. Funciona para mi. Gracias @camh

— Vikas Goel

107

a veces es el resultado de problemas de montaje, por lo que desmontaría el sistema de archivos o el directorio que está tratando de eliminar:

umount / path

— kip2
fuente

55

Son las cuatro menos cuarto. Gracias hombre, me salvaste la noche. Divertidísimo. En una sola línea - tanto tiempo perdido

— --.-

1

mi problema era un directorio de registro montado como / dev / mapper / vg00-root

— Spikolynn

1

Me ayudó a salir de un atasco similar en winders.

— Jon

1

en mi caso, Jenkins no desmontó el directorio chroot después de cancelar la tarea

— zarkone el

1

en mi caso, desmontar con ubuntu escritorio funcionó !! Gracias

— JRichardsz

14

Yo uso fuserpara este tipo de cosas. Enumerará qué proceso está utilizando un archivo o archivos dentro de un montaje.

— BillThor
fuente

fuserayuda solo en el caso específico cuando desea desmontar un sistema de archivos. Aquí el problema es encontrar qué está usando un archivo específico.

— Gilles

@Gilles: también funciona para archivos.

— BillThor

Lo sentimos, objeción incorrecta: fuserno ayuda aquí porque el problema es encontrar todos los archivos abiertos en un árbol de directorios. Puede indicar lsofque muestre todos los archivos y filtros, o que sea recurrente; fuserno tiene ese modo y debe invocarse en cada archivo.

— Gilles

@Giles: las fuserobras serán listas. Intente fuser /var/log/*, si hay registros abiertos, le dirá cuáles y quién lo tiene abierto. Si un comodín simple, no funciona, findcon o sin xargshará el trabajo.

— BillThor

1

lsofno estaba en mi camino mientras fuserestaba, lo que me permitió encontrar la ID del proceso ofensivo para matar, así que + 1 + gracias.

— stevesliva

12

Aquí está la solución:

Entra en el directorio y escribe ls -a
Encontrarás un .xyzarchivo
vi .xyz y mira cuál es el contenido del archivo
ps -ef | grep username
Verá el contenido .xyz en la octava columna (última fila)
kill -9 job_ids - donde job_ids es el valor de la segunda columna del contenido correspondiente al error correspondiente en la octava columna
Ahora intente eliminar la carpeta o el archivo.

— usuario73011
fuente

44

Sería interesante saber de dónde vienen esos misteriosos archivos.

— John WH Smith

9

Tuve este mismo problema, construí una línea que comenzó con la recomendación @camh:

lsof +D ./ | awk '{print $2}' | tail -n +2 | xargs kill -9

El awkcomando toma el PIDS. El tailcomando se deshace de la molesta primera entrada: "PID". Solía -9matar, otros podrían tener opciones más seguras.

— Choylton B. Higginbottom
fuente

1

Para hacerlo más universal, puede usar ./ para el directorio actual en lugar de log /

— user2589273

Buen punto, @ user2589273. Actualizado.

— Choylton B. Higginbottom

5

Tuve este problema cuando una prueba automatizada creó un disco ram. Los comandos sugeridos en las otras respuestas lsofy no fuserfueron de ayuda. Después de las pruebas, intenté desmontarlo y luego eliminar la carpeta. Estuve realmente confundido por años porque no podía deshacerme de él, ¡seguía ocupando "Dispositivo o recurso ocupado" !

Por accidente descubrí cómo deshacerme de un ramdisk. Tuve que desmontarlo la misma cantidad de veces que ejecuté el mountcomando, es decir sudo umount path

Debido al hecho de que fue creado usando pruebas automáticas, se montó muchas veces, por lo que no pude deshacerme de él simplemente desmontándolo una vez después de las pruebas. Entonces, después de desmontarlo manualmente muchas veces, finalmente se convirtió nuevamente en una carpeta normal y pude eliminarlo.

¡Espero que esto pueda ayudar a alguien que se encuentre con este problema!

— glorifobia
fuente

5

Experimento esto con frecuencia en servidores que tienen sistemas de archivos de red NFS. Supongo que tiene algo que ver con el sistema de archivos, ya que los archivos generalmente se llaman así .nfs000000123089abcxyz.

Mi solución típica es renombrar o mover el directorio principal del archivo, luego volver más tarde en un día o dos y el archivo se habrá eliminado automáticamente, momento en el que tengo la libertad de eliminar el directorio.

Esto suele suceder en directorios donde estoy instalando o compilando bibliotecas de software.

— usuario5359531
fuente

4

Refiriéndose a la pregunta anterior de Prabhat, tuve este problema en Macos High Sierra cuando abandoné un proceso de encfs, el reinicio lo resolvió, pero esto

ps -ef | grep name-of-busy-dir

Me mostró el proceso y el PID (columna dos).

sudo kill -15 pid-here

arreglado.

— bil
fuente

Esto funcionó para mí también. ¿Cuál es el -15?

— O.rka

3

Si tiene el servidor accesible, intente

Eliminar ese directorio del servidor

O, desmonte y monte de nuevo, intente umount -l: lazy umount si enfrenta algún problema en el montaje normal.

Yo también tuve este problema donde

lsof +D path : no da salida

ps -ef : no proporciona información relevante

— Prabhat Kumar Singh
fuente