Servidor Linux sin espacio

31

Me han hecho esta pregunta en dos entrevistas consecutivas, pero después de algunas investigaciones y verificaciones con varios administradores de sistemas, no he recibido una buena respuesta. Me pregunto si alguien puede ayudarme aquí.

Un servidor no tiene espacio en disco. Observa un archivo de registro muy grande y determina que es seguro eliminarlo. Elimina el archivo pero el disco aún muestra que está lleno. ¿Qué causaría esto y cómo lo solucionaría? ¿Y cómo encontrarías qué proceso está escribiendo este enorme archivo de registro?

— ewwhite
fuente

3

Necesita hablar con mejores administradores de sistemas. Esto es algo trivial.

— womble

2

Trivial, pero la situación y la pregunta surgen con la suficiente frecuencia ...

— ewwhite

¿El OP podrá aceptar esto?

— ewwhite

55

Trivial o no, para alguien que no habla * nix con fluidez (por ejemplo, principalmente un administrador de Windows), esto es algo bueno para aprender.

— John Gardeniers

56

Esta es una pregunta de entrevista común y una situación que surge en una variedad de entornos de producción.

Las entradas del directorio del archivo se han eliminado, pero el proceso de registro aún se está ejecutando. El sistema operativo no reclamará el espacio hasta que se hayan cerrado todos los identificadores de archivo (por ejemplo, se haya eliminado el proceso) y se hayan eliminado todas las entradas de directorio. Para encontrar el proceso de escritura en el archivo, deberá usar el lsofcomando.

La otra parte de la pregunta a veces puede ser "¿cómo se borra un archivo en el que se está escribiendo sin matar el proceso?" Idealmente, debería "poner a cero" o "truncar" el archivo de registro con algo así como en : > /var/log/logfilelugar de eliminar el archivo.

— ewwhite
fuente

1

... o fuser.

— Steven lunes

1

Expandir un poco: hasta que desaparezcan todas las referencias a un archivo en el disco, ese espacio no puede ser utilizado por otra cosa. Eso incluye identificadores de archivos. Eso también permite que este truco funcione: serverfault.com/questions/45237/link-to-a-specific-inode

— Jeff Ferland

1

Si ha no-clobberestablecido, intente:>| /var/log/logfile

— Belmin Fernández

2

Hago una variante de esta pregunta en cada entrevista: "Recibes mensajes llenos de disco. dfDices que no tienes espacio, dudice que apenas estás usando ninguno. ¿Qué lo está causando y por qué las dos herramientas no están de acuerdo?"

— voretaq7

¿Qué hacer si después > /var/log/filedel espacio en el disco todavía al 100%? El archivo de registro parece estar vacío ... pero solo después de reiniciar el programa que escribe en este archivo de registro, se recupera el espacio. ¿Hay alguna manera de recuperar el espacio en disco sin reiniciar el programa?

— alemani

14

Todavía hay otro enlace al archivo (ya sea enlace duro o identificador de archivo abierto). Eliminar un archivo solo elimina la entrada del directorio; los datos del archivo y el inodo permanecen hasta que se haya eliminado la última referencia.

Es una práctica algo común que un servicio cree un archivo temporal y lo elimine de inmediato mientras mantiene el archivo abierto. Esto crea un archivo en el disco, pero garantiza que el archivo se eliminará si el proceso finaliza de manera anormal, y también evita que otros procesos pisoteen accidentalmente el archivo. MySQL hace esto, por ejemplo, para todas sus tablas temporales en disco. El malware a menudo usa tácticas similares para ocultar sus archivos.

En Linux, puede acceder convenientemente a estos archivos eliminados como /proc/<pid>/fd/<filenumber>.

— tylerl
fuente

8

No soy un administrador de sistemas, pero por lo que he reunido en Unix.SE, un sistema Linux en realidad no eliminará un archivo (marcará el espacio como libre / reutilizable) después de que esté desvinculado hasta que todos los descriptores de archivo que los señalen tengan estado cerrado Entonces, para responder a la primera parte, el espacio aún no está libre porque un proceso todavía lo está leyendo. Para responder a la segunda, puede ver con qué proceso está usando el archivo lsof.

— Kevin
fuente

2

Una respuesta alternativa además de la respuesta obvia de enlace duro / archivo abierto: ese archivo es un archivo (muy) escaso como /var/log/lastlogen RHEL que en realidad no estaba ocupando tanto espacio. Eliminarlo tuvo muy poco impacto, por lo que debe mirar el siguiente archivo más grande.

— Alexios
fuente

1

Si el proceso de escritura del archivo es root, se escribirá en el espacio de archivo reservado del superusuario. El sistema de archivos tiene este espacio para mantener un sistema operativo en caso de que una tarea del usuario llene el disco. Este espacio (por defecto, 5% por defecto) es invisible para muchas herramientas.

lsof puede mostrarle qué proceso ha bloqueado el archivo, ergo le está escribiendo.

— Alguien
fuente

1

También puede ajustar este porcentaje de reserva usando tune2fs. Esta puede ser una forma rápida de permitir que el servidor continúe ejecutándose mientras libera espacio en disco.

— sjbotha

1

Además del archivo abierto por un proceso, un segundo caso es cuando tiene un sistema de archivos que admite instantáneas como btrfso ZFS.

Por ejemplo, toma una instantánea con ese enorme archivo de registro existente. Si elimina el archivo ahora, eliminará solo el delta. Y el delta se elimina solo cuando el archivo no está en uso.

Ver también:

Un tercer caso es cuando tiene un sistema de archivos que admite la desduplicación a nivel de bloque y la mayor parte del archivo es idéntico a otro archivo. No espero que esto suceda para un registro a menos que tenga un contenedor o VM que envíe los registros a un contenedor de syslog o VM que comparta el mismo FS para que el contenido del registro sea idéntico.

— Mircea Vutcovici
fuente