Encarnaciones de Filesystems llenos con Linuxdoesmatter

1:40:45
 
공유
 

Fetch error

Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on June 28, 2021 12:37 (1M ago)

What now? This series will be checked again in the next hour. If you believe it should be working, please verify the publisher's feed link below is valid and includes actual episode links. You can contact support to request the feed be immediately fetched.

Manage episode 288479748 series 1898587
Player FM과 저희 커뮤니티의 Eduardo Collado 콘텐츠는 모두 원 저작자에게 속하며 Player FM이 아닌 작가가 저작권을 갖습니다. 오디오는 해당 서버에서 직접 스트리밍 됩니다. 구독 버튼을 눌러 Player FM에서 업데이트 현황을 확인하세요. 혹은 다른 팟캐스트 앱에서 URL을 불러오세요.

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/serv_example (intro)

Después de un ratito ¡No es instantáneo! Tecleamos

# df -hP |grep /var 

y vemos como le ha sentado la rotación forzada (va por cron normalmente).

Todo parece estar bien y no tengo espacio /var sigue lleno ¿Qué hago?

Hay que buscar una solución si no estamos en BH.

CASO REAL 1:

La partición /var/crash u otra equivalente ocupa 500M está montada en su propio FS pero ninguna aplicación hace uso de ella. Pertenece al mismo VG que /var.

La reduzco (lvm) excepcionalmente. Hay que evitar reducir filesystem en máquinas en producción. lvm es maravilloso pero el tema de reducir todavía da disgustos. En el caso de /var/crash se arriesga poco o nada. Lo que gano de espacio libre lo uso para extender /var

CASO REAL 2:

Detecto cierta cantidad de ficheros que se podrían comprimir y así ganar espacio. Borrar nunca.

# tar –czvf fichero.tgz fichero1 fichero2 … ficheroN

Solución: En BH pido disco a almacenamiento (dpto. Storage) procedo a un extensión del LV mapeado a /var

pvcreate vgextend y lvextend

Poner a cero el tamaño de un log si es que es procedente:

# > fichero.log ó # cat /dev/null > fichero.log

# logger “puesto a cero fichero.log por incidente P1 INC345678” si fuese /var/log/messages

Nota:

Limpiar residuos de Gestores de Paquetes basados en DPKG y YUM suele también liberar un espacio razonable y muy valioso cuando estamos “apurados” en /var:

# sudo apt-get clean en Ubuntu, hay más comandos y mejor seguir una secuencia.

# sudo yum clean all en CentOS también hay más comandos y mejor seguir una secuencia.

Partición /opt

Causa

Aquí están los Aplicativos, Bases de Datos, software variado y opcional como su nombre indica, etc.

La causas suelen ser muy variadas generalmente se resuelve por parte de los responsables de las aplicaciones que hacen “limpieza” o debido a la evolución de la aplicación necesitará ya más espacio en cuyo caso extendemos. Una vez aclarado con el otro equipo… nos piden extender.

# lvextend –L +10G /dev/mapper/vg_opt-lv_oracle -r 

añado 10G al filesystem /opt mapeado al LV /dev/mapper/vg_opt-lv_oracle

Si omito el –r al final tendré que hacer posteriormente

# resize2fs /dev/mapper/vg_opt-lv_oracle

si /opt es un FS tipo ext4

# xfs_grow /dev/mapper/vg_opt-lv_oracle 

si /opt es un FS tipo XFS.

#df –hP |grep /opt 

revelará la nueva extensión del FS /opt

Partción /home

Causa

Los usuarios con derecho a Shell vía SSH suben archivos a sus directorios pues tienen derecho a ello

/home/user01 /home/user02 ....
# du –bsh /home/* 

nos dirá la cantidad ocupada por cada directorio de usuario.

El directorio /home y los directorios de cada usuario que cuelgan de /home están diseñados para sostener los ficheros de configuración del entorno: bash_profile. .bashrc, bash_logout, etc.

En /home/user01/.ssh la clave pública y privada y más mecanismos de ssh.

El espacio asignado a /home suele ser suficiente pero si un usuario o varios empiezan a subir librerías, binarios, herramientas de trabajo propias, etc. Quizá haya que sugerirles que toda esa actividad la hagan en otro lado en el que tenga permisos necesarios que no sea /home/user0X o extenderemos /home (lo cual es menos habitual).

Asumiendo que van a necesitar espacio en /home para algo más que los fichero de inicialización y entorno se asignará a esta partición un espacio realista con las necesidades de los usuarios y se aplicará una política de cuotas.

Extensión del FS /opt desde la capa de Storage y con multipath, host conectado a la cabina de almacenamiento por fiber channel.

1.- Pedimos al Storage team que nos dé un disco de por ejemplo 50 Gigas.

2.- El equipo de Storage crea la LUN y la exporta a nuestro equipo. No dan también el ID de la LUN. Supongamos que es 60000970000297500059533030333136

3.- Desde mi equipo tecleo:

# multipath -ll |grep -e 60000970000297500059533030333136

Caso a) Veo el dispositivo ¡perfecto!

Caso b) No lo veo, nos toca scanear:

# echo "- - -" > /sys/class/scsi_host/host0/scan # echo "- - -" > /sys/class/scsi_host/host1/scan # echo "- - -" > /sys/class/scsi_host/host2/scan

Hay tb un bucle for muy famoso para hacer esto.

# multipath -ll |grep -e 60000970000297500059533030333136 … mpathb(60000970000297500059533030333136) dm-3 LIO-ORG ,IBLOCK size=50g features=‘0’ hwhandler=‘0’ wp=rw ‘-+- policy=‘service-time 0’ prio=1 status=active ‘- 2:0:0:2 sdb 8:16 active ready running ….

Ya aparece mpathb antes del escaneo no aparecía.

/dev/mapper/mpathb

4.- Comandos lvm:

# pvcreate /dev/mapper/mpathb # vgextend /dev/mapper/vg_opt /dev/mapper/mpathb # lvextend –L +10G /dev/mapper/vg_opt-lv_oracle -r # df –hP |grep /opt

Revelará la extensión efectuada. Tendremos 10G más que antes. Y quedan 40G de reserva para futuras extensiones.

Resumen

  1. Diseñar apropiadamente el tamaño de las particiones.
  2. Asignar a /boot /tmp /var/ /opt /home su propia partición.
  3. Chequear los settings de ficheros de configuración de las rotaciones y su frecuencia (cron).
  4. Rotar, comprimir, borrar (solo con permiso) el material muy antiguo o en desuso para ganar espacio.
  5. Plantearse una política de cuotas en /home si fuese necesaria.
  6. Plantearse si el LogLevel del servicio es el necesario y filtrar mensajes recurrentes que puedan ser innecesarios.
  7. Si después de todas las indagaciones descubrimos que el espacio asignado es insuficiente. Extender pero esto siempre será lo último.

Addendum

Falsa alarma de FS lleno. Se produce de vez en cuando llega una alarma y cuando se va es investigar el FS su nivel de ocupación es correcto. La alarma recurrente nos hace colocar un script de la Shell que se ejecute cada, por ejemplo, media hora. Lo dejamos dos días (48 horas) esto implicará 96 “muestras” para ver si realmente este se llena o no. Lo podemos encajar con un cron o con un nohup si el script tiene sleeps de 30×60=1800 segundos

254 에피소드