Come posso limitare le dimensioni del mio syslog?

Ho il computer di mia madre con Ubuntu 12.04 LTS. Ha funzionato bene, ma all'improvviso tutto il syslog si è riempito. E riempiendo intendo che ho appena eliminato un file /var/log/syslogdi dimensioni pari a 400 GB. Sì - Gigabyte.

Mentre sono sicuro che ci fossero alcune informazioni utili lì dentro, non sono sicuro che 400 GB siano qualsiasi tipo di informazione da esaminare. E la cosa davvero sorprendente è che è successo in un periodo di 8 ore - avevo corso dfverso mezzogiorno e tra allora e il suo disco si è riempito del 30% (da poco meno del 70% al 100%).

Cosa potrebbe causare questo e come posso risolverlo? `

EDIT Sembra che l'USB sia l'offensore:

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

Dovresti scoprire cosa sta causando la grande quantità di messaggi, come se risolvi questo problema, allora aggiusti il ​​file di registro di grandi dimensioni.

Tuttavia, fino ad allora è possibile inserire una base di rotazione del registro su una delle opzioni seguenti.

• ora (es. ruota ogni giorno)
• dimensione (es. ruota quando il file raggiunge 10mb)

Questo sarà già impostato sul sistema per impostazione predefinita: /etc/logrotate.d/rsyslog

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

Da questo puoi vedere che ruoterà quotidianamente il file / var / log / syslog e manterrà 7 copie del file ruotato.

Puoi cambiarlo per ruotare su un limite di dimensione, ad esempio 1mb o ridurre il numero di copie memorizzate.

Avviso: questo non risolverà la causa principale del problema , tuttavia ti farà guadagnare un po 'di tempo in quanto impedirà il riempimento del file system.

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

Limitare le dimensioni di logrotate

Apri il /etc/logrotate.d/syslogfile di configurazione

sudo nano /etc/logrotate.d/syslog

Il file sembra sth. piace

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

Aggiungi ad es size 100k . Tra parentesi. Successivamente dovrebbe apparire come:

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

Si noti che ciò limita la dimensione del file in rotazione e non il file syslog effettivo. Salva il file. Al successivo avvio del processo logrotate chron, limiterà la dimensione dei registri ruotati.

Limitare le dimensioni del syslog corrente

Per limitare la dimensione di /var/log/syslog, è necessario modificare /etc/rsyslog.d/50-default.confe impostare una dimensione del registro fissa.

Aggiungi o modifica questa impostazione, cambiando la seguente riga in /etc/rsyslog.d/50-default.conf:

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

Ecco un estratto del manuale di rsyslog :

Canali di uscitasono definiti tramite una direttiva $ outchannel. La sua sintassi è la seguente: $ nome del canale, nome file, dimensione massima, nome azione su dimensione massima è il nome del canale di output (non il file), nome-file è il nome del file in cui scrivere , dimensione massima la dimensione massima consentita e azione su dimensione massima un comando da emettere quando viene raggiunta la dimensione massima. Questo comando ha sempre esattamente un parametro. Il binario è quella parte di action-on-max-size prima del primo spazio, il suo parametro è tutto dietro quello spazio. Si noti che viene richiesta una dimensione massima PRIMA di scrivere il messaggio di registro nel file. Quindi assicurati di impostare questo limite ragionevolmente basso in modo che qualsiasi messaggio possa adattarsi. Per la versione corrente, è utile impostarlo 1k in meno del previsto. La dimensione massima deve essere sempre specificata in byte: non ci sono simboli speciali (come 1k, 1m, ...) a questo punto di sviluppo. Tieni presente che $ outchannel definisce solo un canale con "nome". Non lo attiva. Per fare ciò, è necessario utilizzare una linea di selezione (vedi sotto). Quella riga del selettore include il nome del canale più un segno $ davanti. Un esempio potrebbe essere:. : omfile: $ mychannel Nella sua forma attuale, i canali di output forniscono principalmente la possibilità di limitare le dimensioni di un file di output. Per fare ciò, specificare una dimensione massima. Quando viene raggiunta questa dimensione, rsyslogd eseguirà il comando action-on-max-size, quindi riaprirà il file e riproverà. Il comando dovrebbe essere qualcosa di simile a uno script di rotazione del registro o una cosa simile.

Se non esiste alcun comando action-on-max-size o il comando non ha risolto la situazione, il file viene chiuso e non viene mai riaperto da rsyslogd (tranne, ovviamente, eseguendo l'upuping). Questa logica è stata integrata quando abbiamo riscontrato per la prima volta gravi problemi con file di dimensioni superiori a 2 GB, che potrebbero portare al core di dumping di rsyslogd. In tali casi, è più appropriato interrompere la scrittura in un singolo file. Nel frattempo, rsyslogd è stato corretto per supportare file di dimensioni superiori a 2 GB, ma ovviamente solo per i file system e le versioni del sistema operativo che lo fanno. Quindi può ancora avere senso applicare un limite di dimensioni del file di 2 GB.

Qui la dimensione massima è 1 MB, posizionare questa riga prima della *.*; ...riga

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

e cambia la *.*; ...linea in

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

Riavvia rsyslogd

sudo service rsyslog restart

Ho avuto lo stesso problema con una Lexmark Pro915 per due settimane. Ho fatto due cose e ora funziona bene. Ho reinstallato il driver. (Non credo che questo sia stato di aiuto.) Ho rimosso l'estensione USB che stavo usando, che ha reso la lunghezza totale di quasi 15 'di lunghezza e che potrebbe non essere del tutto compatibile. Ho il sospetto che il driver Lexmark per sistemi Linux potrebbe rilevare un segnale scadente o scadente e voler parlarne 10 miliardi di volte al giorno. Prova a migliorare la tua connessione in qualche modo.

Logrotate e soluzioni simili non mi hanno aiutato. Kern.log e syslog insieme registravano più di 1 TB al giorno! Logrotate potrebbe essere utile se fosse possibile impostarlo per l'esecuzione ogni dodici minuti.