web-dev-qa-db-fra.com

Très gros fichiers journaux, que dois-je faire?

( Cette question traite d'un problème similaire, mais il s'agit d'un fichier journal pivoté.)

Aujourd'hui, j'ai reçu un message système concernant l'espace /var très bas.

Comme d'habitude, j'ai exécuté les commandes dans la ligne Sudo apt-get clean, ce qui n'a amélioré que légèrement le scénario. Ensuite, j'ai supprimé les fichiers journaux en rotation, ce qui a encore une fois apporté très peu d'amélioration.

Après examen, je constate que certains fichiers journaux du /var/log sont devenus très volumineux. Pour être précis, ls -lSh /var/log donne,

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

Comme on peut le constater, les deux premiers sont les fautifs. Je suis un peu surpris de savoir pourquoi ces fichiers volumineux n'ont pas été pivotés.

Donc qu'est ce que je devrais faire? Supprimez simplement ces fichiers puis redémarrez? Ou optez pour des mesures plus prudentes?

J'utilise Ubuntu 14.04.

UPDATE 1

Pour commencer, le système n'a que quelques mois. J'ai dû installer le système à partir de rien quelques mois en arrière après un crash de disque dur.

Maintenant, comme conseillé dans cette réponse , j'ai d'abord vérifié les fichiers journaux incriminés en utilisant tail, sans surprise. Ensuite, pour une inspection plus approfondie, j’ai exécuté ce script à partir de même réponse .

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

Le processus a pris plusieurs heures. La sortie était dans la ligne 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/sda3 est mon répertoire personnel. Comme nous pouvons le trouver,

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

Pourquoi un processus voudra-t-il écrire au-delà de la limite n'entre pas dans le cadre de ma compréhension? Peut-être que je voudrai poser une question différente dans ce forum si cela continue même après une mise à jour du système.)

Ensuite, de cette réponse (vous pouvez vérifier this pour une compréhension plus profonde), j’ai exécuté,

Sudo su -
> kern.log
> syslog

Maintenant, ces fichiers n'ont aucune taille. Le système fonctionne correctement avant et après un redémarrage.

Je regarderai ces dossiers (avec d’autres) dans les prochains jours et je ferai un compte rendu
Ils se comportent mal.

En guise de conclusion, les fichiers en cause (kern.log et syslog) sont configurés pour faire l'objet d'une rotation, ainsi que l'inspection des fichiers (grep aidé) à l'intérieur de /etc/logrotate.d/.

UPDATE 2

Les fichiers journaux sont réellement pivotés. On dirait que les grandes tailles ont été atteintes en un seul jour.

filesystemsystemlog
31
Masroor

Supprimez simplement ces fichiers puis redémarrez?

Non, videz-les mais n'utilisez pas rmcar il pourrait en résulter un plantage lors de la saisie de la commande touchpour le recréer.

Méthode la plus courte:

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

Si ce n'est pas le cas, il faudra Sudoname__. Tiré d'un autre réponse sur AU.

AVANT DE FAIRE QUE. Faites un tail {logfile} et vérifiez s’il ya une raison pour qu’ils soient si gros. À moins que ce système ne date de plusieurs années, il ne devrait y avoir aucune raison à cela et résoudre le problème vaut mieux que de laisser cela se poursuivre.

Kern.log et syslog ne devraient normalement pas être aussi gros. Mais comme je l’ai dit: si ce système fonctionne pendant des années et des années, il est peut-être normal que les fichiers soient simplement effacés.

Et pour éviter qu’elle ne devienne aussi grosse à l’avenir: configurez logrotatename__. Il est assez simple et compressera le fichier journal quand il deviendra plus grand que la taille que vous avez définie.

Autre chose: si vous ne voulez pas supprimer le contenu, vous pouvez compresser les fichiers en les compressant ou en les compressant. Cela vous donnera des fichiers probablement 10% de ce qu'ils sont maintenant. C'est-à-dire s'il y a encore de la place sur le disque pour le faire.

38
Rinzwind

Il vaut probablement la peine d'essayer de déterminer ce qui remplit le ou les journaux, soit en les examinant simplement à l'aide de la commande less ou tail.

tail -n 100 /var/log/syslog

ou si les lignes en cause sont trop profondément enfouies pour voir facilement ce qui se passe, quelque chose comme

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

(Remarque: cela peut prendre un certain temps, étant donné la taille des fichiers) qui tentera de supprimer les horodatages, puis comptera les messages les plus fréquents.

19
steeldriver

Ma méthode pour nettoyer les fichiers journaux du système est la suivante. Les étapes 1 et 2 sont facultatives, mais vous devez parfois vérifier les anciens journaux et la sauvegarde est parfois utile. ;-)

  1. Facultatif: Copier le fichier journal

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

  2. Facultatif: Utilisez Gzip sur la copie du journal

    gzip file.log.old

  3. Utilisez/dev/null pour le fichier propre

    cat /dev/null > file.log

Et nous utilisons pour cela les journaux (uniquement sur plusieurs serveurs) logrotate et un script hebdomadaire exécuté par tous les fichiers avec * .1 (ou la rotation suivante) compressés par gzip.

8
zorbon.cz

J'ai installé Ubuntu 16.04 aujourd'hui et j'ai remarqué le même problème. Cependant, j'ai résolu ce problème avec busybox-syslogd. Ouaip! Je viens d'installer ce paquet et le problème a été résolu. :)

$ Sudo apt-get install busybox-syslogd

Après avoir installé ce paquet, réinitialisez syslog et kern.log:

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

J'espère que cette solution simple est utile à d'autres personnes.

3
omluce