Espace libre se raréfiant pour les mises à jour

[Mimile]

Dernier message de la page précédente :

Je viens de jeter un coup d'oeil sur le syslog qui a été re-créé hier après sa suppression quand il pesait 10 Go, ce qui est proprement hallucinant pour un simple fichier texte.

24 heures plus tard, il compte environ 5000 lignes et pèse environ 457 Ko (Je n'ose imaginer combien il comptera de lignes quand il atteindra 10 Go !)

Je dois avouer que je ne comprends strictement rien aux lignes qui y sont contenues.

Je le surveillerai régulièrement et quand il prendra du poids de manière anormale, je l'examinerai.

Cela dit, la méthode que j'ai renseignée plus haut est celle qui est préconisée sur plusieurs sites et même si il y avait quelque chose d'anormal, il me semble qu'en fixant à 250 Mo sa limite à ne pas dépasser, ça devrait faire l'affaire, quitte à créer quelques fichiers compressés.

Je reviendrai le moment venu.

A+

[dagonh]

24 heures plus tard, il compte environ 5000 lignes et pèse environ 457 Ko (Je n'ose imaginer combien il comptera de lignes quand il atteindra 10 Go !)

Normalement, les fichiers log sont périodiquement compressés et archivés (lesquelles archives peuvent être supprimées sans inconvénient autre que de ne plus pouvoir aller vérifier ce qui a pu se produire loin dans le passé). Cette périodicité est, selon les fichiers, mensuelle, hebdomadaire ou quotidienne (et peut être définie dans les paramètres "cron"). Ça évite d'avoir des fichiers qui ne cessent de grossir au fil du temps (un fichier log même de 100 Mo est donc anormal). Là, tes 457 ko de 'syslog' ne sont pas inquiétants, les miens font couramment de 250 à 400 ko/jour.

[Mimile]

Je n'y comprends plus rien.

Hier, je me suis très peu servi de Linux Mint 17.1 car essentiellement, je me suis attaché à agrémenter LMDE2 (invité virtualbox).

Comme je le disais dans mon précédent message (d'hier), syslog pesait 457 Ko ; je n'ai malencontreusement pas prêté attention à kern.log (qui systématiquement pèse le même poids que syslog - du moins, c'est ce que j'ai constaté jusqu'à présent.

Je viens de lancer Linux-Mint 17.1 et j'ai vérifié syslog qui pèse maintenant 821,8 Ko ce qui n'est pas déraisonnable et puis j'ai vérifié kern.log qui, à ma grande stupéfaction pèse maintenant 9,7 Go !!!!

Je l'ai ouvert avec gedit et là, surprise, le fichier commence à la date du 29 août dernier, qui est précisément la date à laquelle je l'ai supprimé pour la première fois (cf. viewtopic.php?f=23&t=279).

On dirait que quand on le supprime, il se régénère d'une manière ou d'une autre ...

En revanche, syslog démarre bien à la date à laquelle je l'ai supprimé (13 septembre).

Les différents log associés à kern.log dans /etc/logrotate.d/rsyslog obéissent docilement à l'option "size 250 MB" en les compressant pour ne plus peser que quelques Ko.

Seul Kern.log a ce comportement extravagant.

Que faire ?

[marcy]

"size 250 MB"

Salut,

Petite erreur de syntaxe. ce n'est pas : size 250MB mais size 250M ( pas de B )

Cela devrait fonctionner comme ça.



Edit : le plus important serait de trouver ce qui provoque les erreurs qui font grossir exagérément les logs.

[Mimile]

Salut

Tous les sites que j'ai consultés mentionnent bien "size xxx MB"

J'ai ramené le quota à 100 MB sans résultat : le temps de passer d'un OS (Debian Jessie ou Archlinux) à Linux Mint, Kern.log pesait de nouveau dans les 10 Go avec comme date de départ le 23 août dernier, alors que je l'ai supprimé à plusieurs reprises depuis lors.

LMDE en virtuel (depuis Linux Mint 17.1) : montage des dossiers partagés non permanent, périphériques USB introuvables, etc.

Ça commence à me faire ch er, copieusement cette version de Linux Mint 17.1.

Autre exemple, la virtualisation de LMDE2 (virtualbox au départ de Linux Mint 17.1) qui me dit que c'est fini : plus question d'activer la 3D sans aucune raison avec un message selon lequel Cinnamon va puiser lourdement sur le CPU.

Je sens que je vais très bientôt virer tout ça et m'en tenir à Archlinux qui depuis des mois ne m'a jamais posé de véritable problème sans que j'obtienne aussitôt une réponse sur le forum (le dernier en date, le passage à systemd, un peu compliqué à assimiler au début pour quelqu'un comme moi, qui n'ai aucune formation de base en informatique).

Et je ne parle pas de Debian Jessie : j'ai essayé d'installer virtualbox : à chaque étape : paquets suggérés : taratata ; je les installe et de nouveau paquets suggérés : taratata ....

J'installe à chaque fois et quand je lance Virtualbox : plantage

Conclusion : je vais aussi virer Debian Jessie et me contenter de W7 et Archlinux, ce qui me fera gagner pas mal de place et me permettra de tester d'autres OS.

Bye bye

[mpat]

salut Mimile.

As-tu essayé
apt-get autoclean
apt-get clean

Regarde la taille de ton /var avant et après ces commandes.

[marcy]

Tous les sites que j'ai consultés mentionnnent bien "size xxx MB"

A chacun ses références et toute évidence, nous n'avons pas les mêmes.

Cependant, je n'ai pas pour habitude de poster une réponse au hasard sous le coup d'une soudaine illumination, mais après avoir testé, personnellement, ce que j'affirme.

Ensuite libre à vous de choisir ou de rejeter mes propositions.

Bye !

[lacktchou]

Cependant, je n'ai pas pour habitude de poster une réponse au hasard sous le coup d'une soudaine illumination, mais après avoir testé, personnellement, ce que j'affirme.

C'est bien, ça! C'est très, très bien!

[L5d]

"size 250 MB"

Salut,

Petite erreur de syntaxe. ce n'est pas : size 250MB mais size 250M ( pas de B )

Cela devrait fonctionner comme ça.



Edit : le plus important serait de trouver ce qui provoque les erreurs qui font grossir exagérément les logs.

Bonjour,
Je relance ce post, car j'ai le même problème, mes log kern.log et syslog deviennent énormes.
je pense que c'est suite aux essais de différents noyaux autres que le 3.13, qui freeze mon système soit au démarrage (écran de login mdm) ou juste après, lorsque "pulseaudio -D" s'initialise. J'ai aussi des freeze si l'écran se met en mode économiseur.

Ma question est : que faut-il chercher dans ces log qui mettrait sur la bonne piste ? et comment ?

[dagonh]

Ma question est : que faut-il chercher dans ces log qui mettrait sur la bonne piste ? et comment ?

Simple : faut repérer le ou les messages qui reviennent des milliers de fois à la suite et qui sont responsables de 99 % du volume de la log (facile), puis identifier le logiciel responsable de ces messages (un peu moins facile).