¿Cómo limito el tamaño de mi syslog?

Tengo la computadora de mi madre con Ubuntu 12.04 LTS. Ha estado funcionando bien, pero todo el syslog repentino se ha estado llenando. Y al llenar me refiero a que acabo de eliminar un /var/log/syslogtamaño de 400 GB. Sí, gigabytes.

Si bien estoy seguro de que había información útil allí, no estoy seguro de que 400 GB sea algún tipo de información para analizar. Y lo que es realmente sorprendente es que sucedió en un período de 8 horas: corrí dfalrededor del mediodía, y entre entonces y ahora su disco se llenó un 30% (de poco menos del 70% al 100%).

¿Qué podría estar causando esto y cómo podría solucionarlo?

EDITAR Parece que el usb es el delincuente:

Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157829] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157836] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157842] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157849] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157857] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157863] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157870] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157877] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157884] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157891] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use

Debe averiguar qué está causando la gran cantidad de mensajes, ya que si soluciona este problema, arregla el archivo de registro grande.

Sin embargo, hasta entonces puede colocar una base de rotación de registros en uno de los siguientes.

• tiempo (por ejemplo, rotar todos los días)
• tamaño (por ejemplo, girar cuando el archivo alcanza los 10 mb)

Esto ya estará configurado en el sistema de forma predeterminada: /etc/logrotate.d/rsyslog

 /var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
            reload rsyslog >/dev/null 2>&1 || true
    endscript
 }

A partir de esto, puede ver que rotará diariamente el archivo / var / log / syslog y conservará 7 copias del archivo rotado.

Puede cambiar esto para rotar en un límite de tamaño, digamos 1 MB o reducir la cantidad de copias que almacena.

Advertencia: Esto no solucionará la causa raíz de su problema , sin embargo, le dará algo de tiempo ya que impedirá que el sistema de archivos se llene.

• Fuente: /etc/logrotate.d/rsyslog
• Fuente: man logrotate

Limite el tamaño de logrotate

Abre el /etc/logrotate.d/syslogarchivo de configuración

sudo nano /etc/logrotate.d/syslog

El archivo se ve algo. me gusta

/var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
....
...

Añadir, por ejemplo, size 100k entre paréntesis. Luego debería verse así:

/var/log/syslog
{
    rotate 7
    size 100k
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Tenga en cuenta que esto limita el tamaño del archivo de los archivos rotativos y no el archivo syslog real. Guarda el archivo. La próxima vez que se inicie el trabajo cron de rotación de registros, limitará el tamaño de los registros rotados.

Limite el tamaño del syslog actual

Para limitar el tamaño de /var/log/syslog, debe editar /etc/rsyslog.d/50-default.confy establecer un tamaño de registro fijo.

Agregue o modifique esta configuración, cambiando la siguiente línea en /etc/rsyslog.d/50-default.conf:

.*;auth,authpriv.none       -/var/log/syslog

Aquí un extracto del manual de rsyslog :

Canales de salidase definen a través de una directiva $ outchannel. Su sintaxis es la siguiente: $ outchannel name, file-name, max-size, action-on-max-size name es el nombre del canal de salida (no el archivo), file-name es el nombre del archivo en el que se va a escribir , max-size el tamaño máximo permitido y action-on-max-size un comando que se emitirá cuando se alcance el tamaño máximo. Este comando siempre tiene exactamente un parámetro. El binario es esa parte de action-on-max-size antes del primer espacio, su parámetro es todo detrás de ese espacio. Tenga en cuenta que se consulta el tamaño máximo ANTES de escribir el mensaje de registro en el archivo. Así que asegúrese de establecer este límite razonablemente bajo para que pueda encajar cualquier mensaje. Para la versión actual, es útil configurarlo 1k más bajo de lo esperado. El tamaño máximo siempre debe especificarse en bytes: no hay símbolos especiales (como 1k, 1m, ...) en este punto de desarrollo. Tenga en cuenta que $ outchannel simplemente define un canal con "nombre". No lo activa. Para hacerlo, debe usar una línea de selección (ver más abajo). Esa línea de selección incluye el nombre del canal más un signo $ delante de él. Una muestra puede ser:. : omfile: $ mychannel En su forma actual, los canales de salida proporcionan principalmente la capacidad de limitar el tamaño de un archivo de salida. Para hacerlo, especifique un tamaño máximo. Cuando se alcanza este tamaño, rsyslogd ejecutará el comando action-on-max-size y luego volverá a abrir el archivo y volverá a intentarlo. El comando debe ser algo así como un script de rotación de registro o algo similar.

Si no hay un comando action-on-max-size o el comando no resolvió la situación, el archivo se cierra y rsyslogd nunca lo vuelve a abrir (excepto, por supuesto, al abrirlo). Esta lógica se integró cuando experimentamos problemas graves por primera vez con archivos de 2gb más grandes, lo que podría conducir a un núcleo de descarga rsyslogd. En tales casos, es más apropiado dejar de escribir en un solo archivo. Mientras tanto, rsyslogd se ha corregido para admitir archivos de 2 gb más grandes, pero obviamente solo en sistemas de archivos y versiones de sistemas operativos que lo hacen. Por lo tanto, aún puede tener sentido aplicar un límite de tamaño de archivo de 2 gb.

Aquí el tamaño máximo es de 1 MB, coloque esta línea antes de la *.*; ...línea

$outchannel mysyslog,/var/log/syslog,1048576

y cambia la *.*; ...línea a

*.*;auth,authpriv.none  :omfile:$mysyslog

Reiniciar rsyslogd

sudo service rsyslog restart

Tuve el mismo problema con un Lexmark Pro915 durante dos semanas. Hice dos cosas y ahora funciona bien. Reinstalé el controlador. (No piense que esto fue lo que ayudó.) Saqué la extensión USB que estaba usando, que hizo que la longitud total fuera de casi 15 'de largo y que podría no haber sido totalmente compatible. Sospecho que el controlador Lexmark para sistemas Linux podría estar detectando una señal pobre o mal programada y querer informarle sobre eso 10 mil millones de veces al día. Intenta mejorar tu conexión de alguna manera.

Logrotate y soluciones similares no me ayudaron. ¡Kern.log y syslog juntos registraban más de 1 TB al día! Logrotate podría ayudar si pudiera configurarlo para que se ejecute cada doce minutos.