linux - temporales - rm no libera el espacio de disco

ver espacio en disco linux (10)

He obtenido un archivo de registro de 2.5 gb, pero parece que no ha liberado espacio.

Yo si:

rm /opt/tomcat/logs/catalina.out

luego esto:

df -hT

y df informó que mi /opt mount aún está 100% usado.

¿Alguna sugerencia?

Tu problema:

Es posible que un programa en ejecución todavía esté reteniendo el archivo.

Tu solución:

Según las otras respuestas aquí, simplemente puede cerrar tomcat para evitar que se aferre al archivo.

Si esa no es una opción, o si simplemente desea más detalles, revise esta pregunta: busque y elimine archivos grandes que están abiertos pero que se han eliminado ; sugiere algunas formas más duras para manejarlo que pueden ser más útiles para su situación .

Más detalles:

El sistema de archivos linux / unix considera que los archivos "abiertos" son otro nombre para ellos. rm elimina el "nombre" del archivo como se ve en el árbol del directorio. Hasta que los controladores estén cerrados, los archivos aún tienen más "nombres" y, por lo tanto, el archivo aún existe. El sistema de archivos no recupera archivos hasta que estén completamente sin nombre.

Puede parecer un poco extraño, pero hacerlo de esta manera permite cosas útiles como habilitar enlaces simbólicos. Los enlaces simbólicos se pueden tratar esencialmente como un nombre alternativo para el mismo archivo.

Es por esto que es importante que siempre llame a sus idiomas equivalentes a close () en un manejador de archivo si ya ha terminado. Esto notifica al SO que el archivo ya no se usa. Aunque a veces esto no puede ser ayudado , lo cual es el caso con Tomcat. Consulte la respuesta de Bill Karwin para leer por qué.

Dependiendo del sistema de archivos, esto generalmente se implementa como un tipo de recuento de referencia, por lo que puede no haber ningún nombre real involucrado. También puede volverse extraño si elementos como stdin y stderr se redireccionan a un archivo u otro bytestream (lo más común es que se haga con servicios).

Toda esta idea está estrechamente relacionada con el concepto de '' inodes '', por lo que si eres del tipo curioso, te recomiendo que lo consultes primero.

Discusión

Ya no funciona tan bien, pero antes podías actualizar todo el sistema operativo, iniciar un nuevo http-daemon con las nuevas bibliotecas y finalmente cerrar el viejo cuando no se atienden más clientes (liberando las manijas viejas). Los clientes http ni siquiera perderían el ritmo.

Básicamente, puede eliminar completamente el kernel y todas las bibliotecas ejecutando programas desde "debajo". Pero dado que el "nombre" todavía existe para las copias más antiguas, el archivo todavía existe en la memoria / disco para ese programa en particular. Entonces sería cuestión de reiniciar todos los servicios, etc. Si bien este es un escenario de uso avanzado, es una razón por la cual algunos sistemas Unix tienen años de tiempo de actividad registrados.

Al reiniciar Tomcat, se liberará cualquier retención que Tomcat tenga en el archivo. Sin embargo, para evitar reiniciar Tomcat (por ejemplo, si este es un entorno de producción y no desea bajar los servicios innecesariamente), generalmente puede sobrescribir el archivo:

cp /dev/null /opt/tomcat/logs/catalina.out

O incluso más corto y más directo:

> /opt/tomcat/logs/catalina.out

Utilizo estos métodos todo el tiempo para borrar los archivos de registro de los procesos actuales del servidor en el curso de la solución de problemas o la eliminación del disco. Esto deja el inodo solo, pero borra los datos reales del archivo, mientras que intentar eliminar el archivo a menudo no funciona o, al menos, confunde el registro del proceso en ejecución.

Como FerranB y Paul Tomblin han señalado en este hilo, el archivo está en uso y el espacio en el disco no se liberará hasta que se cierre el archivo.

El problema es que no se puede indicar el proceso Catalina para cerrar catalina.out , porque el manejador de archivo no está bajo el control del proceso java. Se abrió mediante la redirección de E / S del shell en catalina.sh cuando se inició Tomcat. Solo al finalizar el proceso de Catalina, puede cerrarse ese identificador de archivo.

Hay dos soluciones para prevenir esto en el futuro:

No permita que la salida de las aplicaciones de Tomcat vaya a catalina.out . En su lugar, use la propiedad swallowOutput y configure los canales de registro para la salida. Los registros gestionados por log4j se pueden rotar sin reiniciar el proceso de Catalina.
Modifique catalina.sh para canalizar salida a cronolog en lugar de simplemente redireccionar a catalina.out . De esa forma, cronolog rotará los registros por usted.

Como otros sugirieron, el archivo probablemente aún esté abierto por otros procesos. Para saber por cuáles, puede hacer

lsof /opt/tomcat/logs/catalina.out

que te enumera los procesos. Probablemente encuentres a Tomcat en esa lista.

Es la rm journaled / scheduled? Pruebe con un comando ''sincronizar'' para forzar la escritura.

Ingrese el comando para verificar qué archivos borrados ocuparon la memoria

$ sudo lsof | grep deleted

Mostrará el archivo eliminado que todavía conserva memoria.

Luego mata el proceso con pid o nombre

$ sudo kill <pid> $ df -h

compruebe ahora que tendrá la misma memoria

Si no, escriba el comando a continuación para ver qué archivo ocupa la memoria

# cd / # du --threshold=(SIZE)

mencionar cualquier tamaño que muestre qué archivos ocupan más del tamaño del umbral y eliminar el archivo

Reinicie Tomcat, si el archivo está en uso y lo elimina, el espacio estará disponible cuando finalice ese proceso.

Si algo todavía tiene abierto, el archivo no desaparecerá. Probablemente necesites indicar catalina de alguna manera para cerrar y volver a abrir sus archivos de registro.

Si hay un segundo enlace fijo al archivo, no se eliminará hasta que también se elimine.

la mejor solución es usar ''echo'' (como sugerencia de @ejoncas):

$ echo '''' > huge_file.log

Esta operación es bastante segura y rápida (elimina aproximadamente 1G de datos por segundo), especialmente cuando está operando en su servidor de producción.

No elimine simplemente este archivo con ''rm'' porque primero debe detener el proceso de escritura, de lo contrario, el disco no se liberará.

consulte: http://siwei.me/blog/posts/how-to-deal-with-huge-log-file-in-production