File di registro molto grandi, cosa devo fare?

( Questa domanda riguarda un problema simile, ma parla di un file di registro ruotato.)

Oggi ho ricevuto un messaggio di sistema riguardante uno /varspazio molto ridotto .

Come al solito, ho eseguito i comandi nella riga del sudo apt-get cleanquale ho migliorato leggermente lo scenario. Quindi ho eliminato i file di registro ruotati che hanno fornito ancora un piccolo miglioramento.

Dopo aver esaminato, ho scoperto che alcuni file di registro /var/logsono diventati molto grandi. Per essere precisi, ls -lSh /var/logdà,

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

Come possiamo vedere, i primi due sono quelli offensivi. Sono leggermente sorpreso dal fatto che file così grandi non siano stati ruotati.

Quindi cosa dovrei fare? Basta eliminare questi file e riavviare? O fare qualche passo più prudente?

Sto usando Ubuntu 14.04.

AGGIORNAMENTO 1

Per cominciare, il sistema ha solo diversi mesi. Ho dovuto installare il sistema da zero un paio di mesi fa dopo un crash del disco rigido.

Ora, come consigliato in questa risposta , ho prima controllato i file di registro offensivi utilizzando tail, nessuna sorpresa lì. Quindi, per un'analisi più approfondita, ho eseguito questo script dalla stessa risposta .

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

Il processo è durato diverse ore. L'output era in linea con

/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/sda3è la mia directory home. Come possiamo trovare,

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

Perché un processo vorrà scrivere oltre il limite è in realtà al di fuori dell'ambito della mia comprensione. Forse vorrei porre una domanda diversa in questo forum se continua anche dopo un aggiornamento del sistema.)

Quindi, da questa risposta (potresti voler controllare questo per una comprensione più profonda), ho eseguito,

sudo su -
> kern.log
> syslog

Ora, questi file hanno dimensioni zero. Il sistema funziona correttamente prima e dopo il riavvio.

Guarderò questi file (insieme ad altri) nei prossimi giorni e riferirò di nuovo nel caso in
cui si comportassero fuori linea.

Come nota finale, entrambi i file offensivi ( kern.loge syslog) sono impostati per essere ruotati, come mostra l' ispezione dei file ( grepaiutati) all'interno /etc/logrotate.d/.

AGGIORNAMENTO 2

I file di registro vengono effettivamente ruotati. Sembra che le grandi dimensioni siano state raggiunte in un solo giorno.

Basta eliminare questi file e riavviare?

No. Svuotali ma non utilizzali rmperché potrebbe finire per bloccare qualcosa mentre stai digitando il touchcomando per ricrearlo.

Metodo più breve:

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

In caso contrario, richiederà sudo. Tratto da un'altra risposta su AU.

PRIMA DI FARLO. Fai un tail {logfile}e controlla se c'è una ragione per cui sono così grandi. A meno che questo sistema non abbia diversi anni, non ci dovrebbero essere ragioni e risolvere il problema è meglio che lasciarlo andare.

Sia kern.log che syslog normalmente non dovrebbero essere così grandi. Ma come ho detto: se questo sistema è attivo e funzionante per anni e anni potrebbe essere normale e i file devono solo essere cancellati.

E per evitare che diventi così grande in futuro: l'installazione logrotate. È piuttosto semplice e comprime il file di registro quando diventa più grande di una dimensione su cui lo imposti.

Un'altra cosa: se non si desidera eliminare i contenuti, è possibile comprimere i file tagtandoli o comprimendoli. Ciò ti farà finire con i file probabilmente il 10% di quello che sono ora. Cioè se c'è ancora spazio sul disco per farlo.

Probabilmente vale la pena provare a stabilire cosa sta riempiendo il / i registro / i - semplicemente esaminandoli visivamente usando il comando lessotail

tail -n 100 /var/log/syslog

o se le linee offensive sono troppo profondamente sepolte per vedere facilmente cosa sta succedendo, qualcosa del genere

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: questo potrebbe richiedere del tempo, dati file così grandi) che tenterà di eliminare i timestamp e quindi contare i messaggi che si verificano più frequentemente.

Il mio metodo per pulire i file di registro di sistema è questo. I passaggi 1 e 2 sono facoltativi, ma a volte è necessario controllare i registri più vecchi e il backup a volte è utile. ;-)

1. Opzionale: copiare il file di registro

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

2. Facoltativo: utilizzare Gzip sulla copia del registro

   gzip file.log.old
   

3. Utilizzare / dev / null per file pulito

   cat /dev/null > file.log
   

E usiamo per questo log (solo su più server) logrotate ed eseguiamo settimanalmente dallo script cron che tutti i file con * .1 (o ruotati successivamente) comprimono con gzip.

Ho installato Ubuntu 16.04 oggi e ho notato lo stesso problema. Tuttavia, ho risolto questo problema con busybox-syslogd. Sì! Ho appena installato quel pacchetto e il problema è stato risolto. :)

$ sudo apt-get install busybox-syslogd

Dopo aver installato quel pacchetto, ripristinare sysloge kern.log:

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

Spero che questa semplice soluzione sia utile per le altre persone intorno.