( Cette question traite d'un problème similaire, mais parle d'un fichier journal avec rotation.)
Aujourd'hui, j'ai reçu un message système concernant l' /varespace très faible .
Comme d'habitude, j'ai exécuté les commandes dans la ligne, sudo apt-get cleance 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 de la base de données /var/logsont devenus très volumineux . Pour être précis, ls -lSh /var/logdonne,
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.
MISE À JOUR 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 indiqué dans cette réponse , j’ai d’abord vérifié les fichiers journaux incriminés tail, sans surprise. Ensuite, pour une inspection plus approfondie, j'ai exécuté ce script à partir de la 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/sda3est 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, à partir de cette réponse (vous pouvez vérifier ceci 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 (ainsi que d’autres) dans les prochains jours et ferai un rapport
s’ils se comportent de manière inacceptable.
Pour terminer, les fichiers incriminés ( kern.loget syslog) sont configurés pour faire l'objet d'une rotation, ainsi que l'inspection des fichiers ( grepaidés) dans les
/etc/logrotate.d/émissions.
MISE À JOUR 2
Les fichiers journaux sont réellement pivotés. On dirait que les grandes tailles ont été atteintes en un seul jour.