( Cette question traite d'un problème similaire, mais il parle d'un fichier journal rotatif).
Aujourd'hui, j'ai reçu un message système concernant un niveau très bas /var espace.
Comme d'habitude, j'ai exécuté les commandes de la ligne de sudo apt-get clean ce qui n'a que légèrement amélioré le scénario. Ensuite, j'ai supprimé les fichiers journaux tournés, ce qui n'a apporté que très peu d'amélioration.
Après examen, je constate que certains fichiers journaux dans le répertoire /var/log est devenu très important. 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 voir, les deux premiers sont les fautifs. Je suis un peu surpris que des fichiers aussi volumineux n'aient pas fait l'objet d'une rotation.
Alors, que dois-je faire ? Supprimer simplement ces fichiers et redémarrer ? Ou prendre des mesures plus prudentes ?
J'utilise Ubuntu 14.04.
MISE À JOUR 1
Pour commencer, le système n'a que quelques mois. J'ai dû installer le système à partir de zéro il y a quelques mois après un crash du disque dur.
Maintenant, comme conseillé dans cette réponse , J'ai d'abord vérifié les fichiers journaux incriminés en utilisant tail Ce n'est pas une surprise. Ensuite, pour une inspection plus approfondie, j'ai exécuté ce script à partir de l'interface de l'entreprise. 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
doneLe processus a duré plusieurs heures. Le résultat était de l'ordre 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 on peut le constater,
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
La raison pour laquelle un processus veut écrire au-delà de la limite est en fait hors de portée de ma compréhension. Peut-être voudrai-je poser une autre question dans ce forum si ce problème est résolu. continue même après une mise à jour du système).
Ensuite, de cette réponse (vous pouvez vérifier este pour une compréhension plus approfondie), je exécuté,
sudo su -
> kern.log
> syslogMaintenant, ces fichiers ont une taille nulle. Le système fonctionne bien avant et après un redémarrage.
J'examinerai ces dossiers (ainsi que d'autres) dans les prochains jours et je ferai un rapport à ce sujet.
ils ont un comportement hors norme.
En guise de conclusion, les deux fichiers incriminés ( kern.log y syslog ), sont réglés pour être tournés, comme l'inspection des fichiers ( grep aidé) à l'intérieur /etc/logrotate.d/ montre.
MISE À JOUR 2
Les fichiers journaux sont en fait tournés. On dirait que les grandes tailles ont été atteintes en un seul jour.
