Cuando gestionas servidores, los logs para saber qué ha pasado son muy importantes. Eso no significa que siempre funcionen como esperamos, y puede que necesites solucionar un algo uso de cpu por parte de logrotate.
El método que te voy a enseñar está relacionado con los archivos generados, es decir, lo puedes utilizar para localizar un fallo en la configuración que copia los archivos log exponencialmente.
Cómo arreglar 100% uso de CPU de logrotate en cualquier Linux
Es posible que siguiendo los pasos puedas encontrar algún otro problema que lo provoca aunque normalmente es el que vamos a solucionar el que causa que logrotate use el 100% de la CPU al ejecutarse.
Antes de empezar, quiero puntualizar que esto puede llevar tiempo, dependiendo del servidor o equipo en el que vayas a hacer el trabajo incluso mucho tiempo. Dependerá directamente de la velocidad de los discos duros, y de la cantidad de archivos, en mi caso cada máquina alrededor de 2 millones de archivos.
Ver uso de CPU de logrotate y parar el proceso
Lo primero será ver si realmente el uso de la CPU se lo está comiendo el logrotate. Para eso puedes simplemente escribir en la terminal:
top o htop
El htop es similar a top pero con más opciones y algo más gráfico. Una vez ejecutes uno de ellos deberías ver algo similar a esto en pantalla entre los primeros procesos:
top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4707 root 20 0 634780 392720 184 R 84.1 37.5 1772:35 logrotate 28424 root 20 0 450640 273328 188 R 81.4 26.1 366:26.31 logrotate
Si logrotate no está usando una gran cantidad de cpu y es otro programa puedes dejarme un comentario y te echo un cable a encontrar el problema.
Ahora toca parar los procesos para que no haya conflictos con los archivos que vamos a tocar:
kill 4707 kill 28424
Es posible que sea un proceso con alguna subtarea y matando uno se pare también el otro, aun así revísalo para estar seguros, ahora top tendría que estar sin procesos comiendo un montón de cpu.
Detectar el problema de logrotate que usa 100% de cpu
Voy a ir directo al grano y a revisar el problema que suele generar este uso de cpu. Para eso vamos a revisar que el archivo de status de logrotate esté bien:
ls -l /var/lib/logrotate/status
Si es muy grande, por ejemplo 40 megas o más, casi seguro que tenemos el problema localizado, ejecuta este otro comando para ver parte del contenido del archivo:
tail -f /var/lib/logrotate/status
Deberías ver algo similar a esto:
"/var/www/dominio/logs/error_log.4.4.2.4.1.3" 2019-11-20-9:38:39 "/var/www/dominio/logs/error_log.3.2.1.1.1.2.4.1.2.1" 2019-11-20-9:38:39 "/var/www/dominio/logs/error_log.1.1.1.1.1.2.1.2.4.2.2" 2019-11-20-9:38:39 "/var/www/dominio/logs/error_log.3.3.4.3.1.2.2.4" 2019-11-20-9:38:39 "/var/www/dominio/logs/access_log.2.1.3.1.3.4.1.1.2.2" 2019-11-20-9:38:39 "/var/www/dominio/logs/access_log.2.4.3.1.2.1.2.1.3.2" 2019-11-20-9:38:39 "/var/www/dominio/logs/error_log.2.2.3.2.1.1.2.1.2.1.3" 2019-11-20-9:38:39 "/var/www/dominio/logs/error_log.3.3.1.1.2.3.1.1.2" 2019-11-20-9:38:39 "/var/www/dominio/logs/error_log.1.3.2.3.3.1.1.2.1.3" 2019-11-20-9:38:39 "/var/www/dominio/logs/error_log.1.1.4.2.1.1.2.2.1.2.1.1" 2019-11-20-9:38:39
Vaya vaya… parece que hemos dado con el problema, hay un montón de logs, y todos tienen un montón de numeritos al final.
Ejecuta este comando en la carpeta donde estén tus logs:
ls /var/www/dominio/logs/ |wc -l
Sirve para ver el total de archivos dentro de una carpeta, no te preocupes si parece que no responde, pues puede tardar un poco en contabilizarlos todos si hay miles o cientos de miles de logs. Debería darte un número al final como a mí:
1954468
Si no quieres esperar una barbaridad no lo pruebes, pero dentro de la carpeta, si listas los archivos habrá algo similar a esto:
… error_log.4.3.2.2.4.3.2.1.1 error_log.4.3.2.2.4.3.2.1 error_log.4.3.2.2.4.3.1.4.1 error_log.4.3.2.2.4.3.1.4 error_log.4.3.2.2.4.3.1.3.2 error_log.4.3.2.2.4.3.1.3.1 error_log.4.3.2.2.4.3.1.3 error_log.4.3.2.2.4.3.1.2.3 error_log.4.3.2.2.4.3.1.2.2 error_log.4.3.2.2.4.3.1.2.1 error_log.4.3.2.2.4.3.1.2 error_log.4.3.2.2.4.3.1.1.4 error_log.4.3.2.2.4.3.1.1.3 error_log.4.3.2.2.4.3.1.1.2 error_log.4.3.2.2.4.3.1.1.1.2 error_log.4.3.2.2.4.3.1.1.1.1 error_log.4.3.2.2.4.3.1.1.1 error_log.4.3.2.2.4.3.1.1 error_log.4.3.2.2.4.3.1 error_log.4.3.2.2.4.3 error_log.4.3.2.2.4.2.4.4 error_log.4.3.2.2.4.2.4.3 …
Por qué logrotate está duplicando archivos en la carpeta de logs
Por supuesto esto no debería ser así, y en este caso, como puedes ver en los nombres de los archivos son los del servidor apache.
Para localizar por qué se están copiando los archivos una y otra vez tenemos que indagar en la configuración de logrotate, y como sabemos que es en apache iremos directamente al archivo de configuración:
cat /etc/logrotate.d/apache-www
"/var/www/*/logs/*"
{
daily
[...]
}
Ahí está el problema, como ves, la línea termina con un asterisco *, y no indica extensión ni nada. Esto significa, que cada día, logrotate cogerá todos los archivos, y los añadirá a la rotación, haciendo que se generen ingentes cantidades de archivos, en mi caso cada día.
Para solucionar esto, basta con poner .log al final, de forma que quede así:
"/var/www/*/logs/*.log"
De esta forma, solo se añadirán los archivos .log de dentro de la carpeta logs, que es como tiene que funcionar, pero no hemos terminado.
Eliminar todos los archivos log incorrectos
Esta es seguramente la tarea más larga aunque también sencilla, y no porque haya que hacer mucho, sino porque como he comentado antes, eliminar una gran cantidad de archivos puede ser muy lento.
Lo primero será parar el servicio que está generando los logs. Sé que puede resultar contraproducente si es un servidor en producción, pero es lo recomendable. Puedes borrar los archivos sin pararlo, pero debes saber que podría dar lugar a errores.
Para parar el servidor de apache en este caso:
service apache2 stop
Ahora toca eliminar los archivos. Tengo un artículo sobre las formas más rápidas de borrar archivos en linux, pero aquí vamos a usar lo más sencillo.
Si tu carpeta de logs con el problema es /var/www/dominio/logs, la borraremos, y luego la volvemos a crear:
rm -rf /var/www/dominio/logs/ mkdir /var/www/dominio/logs
En este momento, y tras el buen rato que puede haber tardado, podemos volver a arrancar el servidor de apache:
service apache2 start
Y a partir de aquí no debería volver a aparecer el problema a no ser que vuelva a cambiar la configuración de logrotate.
Ten ojo con esto, pues si gestionas tu servidor por ejemplo con Ansible, es posible que esté mal configurada la puesta en producción y se vuelva a poner la configuración errónea.
Si quieres probar que logrotate sigue funcionando correctamente puedes ejecutarlo a mano:
logrotate -f /etc/logrotate.conf
No debería aparecer ningún error.
Recuerda que en el caso del tuto el servicio era apache, pero logrotate sirve para rotar los logs de cualquier programa y servicio instalado en el sistema. Puede que en tu caso sea uno diferente, pero las configuraciones están todas en /etc/logrotate.d/, basta con que las revises y encuentres la que tiene el fallo.
Si tienes dudas o al final no has podido solucionarlo dímelo en los comentarios y te echaré un cable.
¿Gestionas servidores? ¿Utilizas algún programa para ello o lo haces a mano? Comenta y comparte