Hoy hablamos con Linuxdoesmatter de filesystems llenos. ¿Cómo actuar ante sistemas de ficheros llenos? ¿qué hacer con esas particiones que se llenan y cómo actuar en cada caso?

Vamos a ir viendo partición por partición.

Partición /boot

Causa

Insuficiente tamaño o comprometerse a mantener un número de Kernels que no caben en el espacio planificado para esta partición.

Consecuencias

Fallará la actualización o parcheo del Kernel.

Soluciones

La solución será borrar los kernels no utilizados, para ello lo primero será comprobar qué kernel estamos utilizando con:

$ sudo uname -r

Y después borrar los kernels:

En Centos:

1.- Borrar kernels anteriores, solo nos quedamos con 2 el actual y el anterior

# package-cleanup --oldkernels --count=2 -y (intro) nota: package-cleanup command is a part of yum-utils

3.- Listar todos los kernels instalados:

# rpm -q kernel
kernel-3.10.0-327.36.3.el7.x86_64
kernel-3.10.0-514.2.2.el7.x86_64
....

4.-Borrar los kernels que sobren

# yum remove kernel-3.10.0-327.36.3.el7.x86_64 kernel-3.10.0-514.2.2.el7.x86_64 (intro)

También tenemos la opción de definir en el yum.conf el límite de kernels:

Editar /etc/yum.conf —–> installonly_limit=2 (esta directiva limita el número. de kernels conservados a 2)

¡¡¡¡¡ NUNCA BORRAR KERNEL CON rm !!!! Se desinstala el paquete.

La solución en Debian:

En este artículo también lo explican muy bien: https://www.linuxadictos.com/como-eliminar-kernels-antiguos-en-debian.html

$ sudo dpkg -l | grep linux-image | awk '{print $2}'

Esto nos mostrará todos los kernels instalados. Ahora hemos de elegir los kernels a eliminar y hacerlo de la manera siguiente:

$ sudo apt remove --purge linux-image-X.XX-X-generic
$ sudo update-grub2
$ sudo reboot

Esto será con cada versión del kernel que queramos eliminar. Si queremos hacerlo de manera automática, existe un programa llamado byobu que lo hará de manera automática. Para ello, primero hemos de instalarlo de la siguiente manera:

$ sudo apt install byobu

Y luego ejecutarlo de la siguiente manera:

$ sudo purge-old-kernels --keep 2

Esto eliminará todos los kernels antiguos y dejará solo dos versiones por seguridad.

Si hay que mantener muchos Kernels y no caben en el tamaño planificado entonces Extendemos el FileSystem /boot . Pero esto siempre será la última opción.

En Ubuntu también podemos controlar los kernels antiguos utilizando las unnatended upgrades como os muestran en el siguiente enlace: https://ciberseguridadtotal.com/actualizaciones-automaticas-en-ubuntu-con-unattended-upgrades/

Partición /tmp

Causa

El aplicativo o algún demonio de Linux generan una cantidad de archivos y directorios temporales desmesurada. Algún servicio en ejecución puede haberse vuelto loco y genera un montón de temporales en /tmp.

Este problema da la cara en los prechecks antes del parcheo o en medio de un deployment (middleware). En medio de un despliegue un FS lleno genera un P1, ventana de mantenimiento en peligro.

Puede agotarse

1.- El espacio.

 $ sudo df –hPT /tmp

2.- Los inodos.

$ sudo df –i /tmp

Pudo en su momento no haberse planificado bien su tamaño o los turnos de limpieza del /tmp.

Consecuencias

1.- Errores en el aplicativo, servicios de Linux, etc.

2.- Nadie excepto root podrá hacer SSH (minfree) a esa máquina. Aunque veamos 100% ocupado en /tmp root tiene un pequeño espacio reservado y podrá arreglar el incidente.

Experimento sugerido en una máquina de test:

PASO UNO: Desde /tmp

$ sudo df –i . (intro) 

Supongamos que el resultado es 45.000 inodes.

PASO DOS: Desde /tmp

$ touch file{1...45000}.txt 

Ahora tenemos los inodes agotados

Intentar SSH a esta máquina desde otra máquina como usuario. No será posible.

Solución

Ojo no se puede borrar para liberar espacio sin medir la consecuencias pueden producirse errores en las aplicaciones. Es importante borrar sólo lo que se haya quedado como “escombro” y ya esté en desuso y no lo que el sistema ha generado recientemente y espera encontrarlo allí cuando le haga falta otra vez antes de ser escombro. De lo contrario ¡¡error!!

Borrar lo que sea más antiguo de 7 días por ejemplo

$ sudo find /tmp/* -mtime +7 -exec rm {} \;

Para identificar ficheros ofensores

$ sudo find /tmp/* -type f -size +50M -exec ls -lrth {} \;  

https://www.sololinux.es/borrar-archivos-temporales-en-linux/ -> Explica cómo cambiar la frecuencia de limpieza de este directorio /tmp

Si todo lo que sucede es normal y sencillamente se planificó mal al tamaño de /tmp. Extenderíamos.

Partición /var

Causa

Los logs del sistema o del aplicativo llenan esta partición antes de la rotación o incluso ni aun rotando se libera el espacio deseable.

Uno de los servicios está generando una desmesurada información de logging. Lo que se llama “running wild” los logs asociados a este servicio crecen a una velocidad desmesurada.

Este problema también da la cara en los prechecks antes del parcheo o en medio de un deployment.

Consecuencias

Pérdida de la información de logging lo cual puede impedir investigar acontecimientos pasados de los cuales hay que dar una explicación. Por ejemplo RCA de algo malo que pasó tal día a tal hora, un acceso root a la máquina sospechoso, causa de una transacción fallida, etc.

Solución

# du –bsh /var/*

Este comando “disk usage” con estas opciones me dirá el tamaño ocupado en cada directorio que cuelgue directamente de /var

# find /var/directorio/ –type f –size +200M

Identificamos ficheros de más de 200M, o lo que estimemos oportuno según la naturaleza de nuestro entorno, en el directorio que cuelga de /var buscando siempre a los ofensores.

¿Hay algún log desbocado?

$ sudo tail –f /var/log/messages

Si vemos que se vuelcan gran cantidad de mensajes.

Configurar /etc/rsyslog.conf para evitar que ciertos mensajes que son lo que están inundando se reflejen/escriban en /var/log/messages

Editamos /etc/rsyslog.conf

# vim /etc/rsyslog.conf

 …
 #### RULES ####
 :msg, contains, “Basis System: “   ~
 :msg, contains, “Break Point Reached”  ~
 ….

Salimos guardando…

# service rsyslog restart

O bien

# systemctl restart rsyslog.service

Syslog, rsyslog, syslog-ng and journald en cada uno lo anterior se hará de alguna manera.

Inserto un evento desde la consola.

# logger “Acabo de apagar los mensajes Basis System: y Break Point Reached debido al P1 INC2345467” si es a /var/log/messages o /var/log/syslog

Otra forma es bajar el nivel de logging por ejemplo de debug (reporta hasta el vuelo de una mosca) a warn.

From least verbose to most verbose: emerg, alert, crit, error, warn, notice, info, or debug

Hay que investigar dónde esta configuración del nivel de logging para cada servicio

Cups: /etc/cups.conf

...
LogLevel warn # de debug a warn
...

Repercutirá en sus logs.

/var/log/cups/{access-,error-,page-}log

En el fichero de configuración de Apache será igual. httpd.conf Centos ó apache2.conf en Ubuntu/Debian

Forzar la rotación:

En /etc/logrotate.d

Están los ficheros que configuran las reglas de rotación. Tamaño mínimo, antigüedad, acción posrotate, etc.

# ls /etc/logrotate.d

cups syslog zabbix-agent centrifydc serv_example …

Por dentro esto fichero son más o menos así:

# cat /etc/logrotate.d/serv_exmaple

/var/directory/logexample.log {

size 50k
copytruncate
create 700 bala bala
rotate 4
weekly
compress
postrotate
/bin/kill -HUP `cat /var/run/myapp.pid 2>/dev/null` 2>/dev/null || true
endscript
}

#

Forzar el rotado:

# logrotate –fv /etc/logrotate.d/se