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:
$ 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:
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 {} ;
-＞ 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 …
[ad_2]
source
