Merci de ton retour.
En 3 ans, il y a peut-être eu des évènements qui n’ont plus d’intérêt maintenant.
Dans un premier temps, pour soulager ton système, supprime ces 3 gros fichiers, reboot, et tu verras progressivement l’évolution des logs.
Bonjour Verner,
J’ai fait de la place et voici le résultat:
root@debian:/home/user1# du -hxd1 / | sort -h
4,0K /mnt
4,0K /opt
4,0K /srv
16K /lost+found
16K /media
68K /tmp
912K /root
10M /sbin
11M /bin
32M /etc
55M /boot
326M /lib
361M /var
3,6G /usr
4,4G /
Cela va de suite beaucoup mieux.
Ce ne sont pas les premières lignes du démarrage d’aujourd’hui qu’il faut regarder mais les motifs répétitifs dans le fichier kern.log.1. Contrairement à ce que tu as écrit, ce fichier ne court pas du 2 au 5 novembre mais du 25 octobre (date de l’arrêt du log précédent kern.log.2.gz) au 2 novembre (date de l’arrêt de kern.log.1). Les autres fichiers kern.log.* ont des tailles modestes donc le problème a dû se produit seulement entre le25 octobre et le 2 novembre.
Pourquoi parles-tu de 3 ans ? Ces logs ne remontent qu’à un mois.
Le résultat, c’est que tu as détruit les preuves et on ne saura pas ce qui s’est passé, sauf si ça se reproduit et tu ne pourras pas le prévenir puisque tu ne sais pas ce que c’était.
1 J'aime
C’est parce que j’avais indiqué avoir fait l’installation de debian il y a 3 ans environs.
Merci pour tes explications.
A partir de quelle taille de dossier peut-on considérer que /var/log doit-être nettoyé?
@pierre40
Si tu compares à mon premier message, tu verras que ça va effectivement mieux !
Surveille ça de temps en temps quand-même.
Si tu ne vois nul-part de messages d’alarme ou de dysfonctionnement, pas trop d’inquiétude pour le moment.
Le transfert d’images était visiblement qu’une grosse coïncidence, une fausse piste.
Pour voir:
systemctl list-unit-files | awk '/log.*bled/'
Voici le résultat de ta commande
root@debian:/home/user1# systemctl list-unit-files | awk '/log.*bled/'
rsyslog.service enabled
syslog.service enabled
Ok. La suite au prochain épisode !
Enjoy.
1 J'aime
Merci à vous 2 pour votre aide précieuse.
Mon aide n’était pas désintéressée. J’attendais quelque chose en retour : des informations. Découvrir pourquoi le volume des messages du noyau est devenu anormalement gigantesque sur une période de temps. Il aurait suffi de supprimer un voire deux des trois fichiers qui contenaient des copies de ces messages, pour libérer sufffisamment d’espace disque et permettre au système de fonctionner normalement pendant un bon moment, et tu aurais pu en conserver au moins un pour l’analyser.
PS : si tu veux aider les lecteurs qui rencontreraient un problème d’espace disque, il vaudrait mieux marquer comme solution le message avec la commande du qui affiche l’espace disque occupé dans chaque répertoire de la racine.
1 J'aime
As-tu souvenir d’un post similaire dans le forum avec un traitement comme tu l’indiques?
@pH
C’est quoi cette manie de vouloir systématiquement tout embrouiller à l’infini ?
Pas la peine de faire un patacaisse parce-que dans une doc « Debian » tu as trouvé une commande ‹ du ›, mais pas exactement les mêmes options que les miennes: et alors ?
Il y a plein de combinaisons possibles… Pas besoin de chercher un doc Debian: tu as le ‹ man › pour ça.
Dans le kit de recherche, j’ai déjà tout donné, mais pas pris le temps d’expliquer il est vrai:
du -hd0 /var/ /usr
Donnera dans un premier temps un aperçu des gros volumes de premiers niveaux.
Inutile d’aller chercher des fichiers de taille 4K dont on se moque éperdumment…
Ensuite, pour affiner la recherche sur les fichiers, il faut utiliser la commande find avec option -size.
find /var /lib* /usr -size +100M -exec ls -sh {} \;
Ma priorité n’était pas de faire un tuto, mais de comprendre précisemment la chronologie de l’affaire pierre40 et pas quelqu’un d’autre.
En espérant être suffisamment clair. Fatigant ces embrouilles totalement inutiles.
C’est plutôt toi qui crées des « embrouilles totalement inutiles ».
Quel « kit de recherche » ? Tu n’a jamais proposé cette commande dans aucun de tes messages de ce sujet, que tu as fait traîner en longueur en demandant un répertoire, puis un nautre, puis encore un autre… mais jamais /var. Résultat : 21 messages pour rien avant que j’intervienne pour faire avancer les choses.
Allez mon gars . Hallucinant. Jamais vu ça.
Salut.
Perso j’ai eu exactement le même problème il y a environ un mois, sur il me semble les mêmes fichiers, et j’avoue qu’après des itérations semblables sur Debian-Facile j’ai fini par purger également les logs « fautifs ». (car moi j’étais à 100% et le serveur X ne démarrait carrément plus!)
Ce que j’ai fait en plus c’est
- dégager des paquets inutiles avec des apt autoremove, apt clean et autres autoclean
- éditer quelque chose dans logrotate qui limite explicitement les log à une taille max, mais je ne retrouve plus le détail à l’instant
- nettoyer un tas d’énormes trucs dans les flatpak, qu’on voit dans var/lib/flatpak, chose qui m’a bien refroidi sur les flatpaks du reste.
H.