Archivos de registro muy grandes, ¿qué debo hacer?

( Esta pregunta trata un problema similar, pero habla de un archivo de registro rotado).

Hoy recibí un mensaje del sistema sobre muy poco /varespacio.

Como de costumbre, ejecuté los comandos en la línea de los sudo apt-get cleancuales mejoré el escenario solo un poco. Luego eliminé los archivos de registro rotados que nuevamente proporcionaron muy poca mejora.

Tras el examen, descubro que algunos archivos de registro en el /var/loghan crecido para ser muy grandes. Para ser específico, ls -lSh /var/logda,

total 28G
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 kern.log
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 syslog
-rw-rw-r-- 1 root              utmp    390K Aug 23 21:47 wtmp
-rw-r--r-- 1 root              root    287K Aug 23 21:42 dpkg.log
-rw-rw-r-- 1 root              utmp    287K Aug 23 20:43 lastlog

Como podemos ver, los dos primeros son los ofensivos. Me sorprende un poco por qué no se han rotado archivos tan grandes.

¿Entonces qué debo hacer? ¿Simplemente elimine estos archivos y luego reinicie? ¿O dar algunos pasos más prudentes?

Estoy usando Ubuntu 14.04.

ACTUALIZACIÓN 1

Para empezar, el sistema tiene solo varios meses. Tuve que instalar el sistema desde cero hace un par de meses después de un bloqueo del disco duro.

Ahora, como se aconseja en esta respuesta , primero revisé los archivos de registro ofensivos usando tail, no es de extrañar. Luego, para una inspección más profunda, ejecuté este script desde la misma respuesta .

for log in /var/log/{syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

El proceso tomó varias horas. La salida estaba en la línea de,

/var/log/syslog :
71209229  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
53929977  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
17280298  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 54763121030042024)
       <snipped>

/var/log/kern.log.1 :
71210257  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
71209212  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 954763121030042024)

( /dev/sda3es mi directorio de inicio. Como podemos encontrar,

lsblk /dev/sda
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0 122.1G  0 part /
├─sda2   8:2    0   7.6G  0 part [SWAP]
└─sda3   8:3    0 801.8G  0 part /home

Por qué un proceso querrá escribir más allá del límite está realmente fuera del alcance de mi comprensión. Tal vez quiera hacer una pregunta diferente en este foro si esto continúa incluso después de una actualización del sistema).

Luego, a partir de esta respuesta (es posible que desee verificar esto para una comprensión más profunda), ejecuté,

sudo su -
> kern.log
> syslog

Ahora, estos archivos tienen cero tamaños. El sistema funciona bien antes y después de un reinicio.

Veré estos archivos (junto con otros) en los próximos días e informaré si
se comportan fuera de línea.

Como nota final, los dos archivos ofensivos ( kern.logy syslog) están configurados para rotarse, como muestra la inspección de los archivos ( grepayudados) en el interior /etc/logrotate.d/.

ACTUALIZACIÓN 2

Los archivos de registro se giran realmente. Parece que los grandes tamaños se alcanzaron en un solo día.

¿Simplemente elimine estos archivos y luego reinicie?

No. Vacíelos pero no los use rmporque podría terminar bloqueando algo mientras está escribiendo el touchcomando para recrearlo.

Método más corto:

cd /var/log
sudo su
> lastlog
> wtmp
> dpkg.log 
> kern.log
> syslog
exit

Si no es root, será necesario sudo. Tomado de otra respuesta en AU.

ANTES DE HACER ESO. Haz una tail {logfile}prueba y comprueba si hay una razón para que sean tan grandes. A menos que este sistema tenga varios años, no debería haber ninguna razón para esto y solucionar el problema es mejor que dejar que esto continúe.

Tanto kern.log como syslog normalmente no deberían ser tan grandes. Pero como dije: si este sistema está funcionando durante años y años, puede ser normal y los archivos solo necesitan borrarse.

Y para evitar que se vuelva tan grande en el futuro: configuración logrotate. Es bastante sencillo y comprimirá el archivo de registro cuando sea más grande que el tamaño en el que lo configuró.

Otra cosa: si no desea eliminar el contenido, puede comprimir los archivos tarrándolos o comprimiéndolos. Eso hará que termines con archivos, probablemente el 10% de lo que son ahora. Eso es si todavía hay espacio en el disco para hacer eso.

Probablemente valga la pena intentar establecer qué está llenando los registros, ya sea simplemente examinándolos visualmente con el comando lessotail

tail -n 100 /var/log/syslog

o si las líneas ofensivas están demasiado enterradas para ver fácilmente lo que ocurre, algo como

for log in /var/log/{dmesg,syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

(nota: esto puede llevar algo de tiempo, dados archivos tan grandes) que intentarán quitar las marcas de tiempo y luego contar los mensajes más frecuentes.

Mi método para limpiar los archivos de registro del sistema es este. Los pasos 1 y 2 son opcionales, pero a veces es necesario verificar los registros antiguos y la copia de seguridad a veces es útil. ;-)

1. Opcional: Copiar archivo de registro

   cp -av --backup=numbered file.log file.log.old
   

2. Opcional: use Gzip en la copia del registro

   gzip file.log.old
   

3. Use / dev / null para limpiar el archivo

   cat /dev/null > file.log
   

Y utilizamos para estos registros (solo en varios servidores) logrotate y ejecutar semanalmente por script cron que comprime todos los archivos con * .1 (o el próximo rotado) por gzip.

Instalé Ubuntu 16.04 hoy y noté el mismo problema. Sin embargo, arreglé esto con busybox-syslogd. ¡Sip! Acabo de instalar ese paquete y el problema se ha resuelto. :)

$ sudo apt-get install busybox-syslogd

Después de instalar ese paquete, reinicie syslogy kern.log:

sudo tee /var/log/syslog /var/log/kern.log </dev/null

Espero que esta solución simple sea útil para otras personas.