[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: blocage au démarrage /var/ plein



Salut,

J’aurais tendance à conseiller ceci :
1) sauvegarder le contenu de /var/log sur un autre support
2) Effacer les logs présent par exemple avec un :
   # find /var/log -type f \( -iname "*.[0-9].log" -o -iname "*.[0-9].log.gz" -o -iname "*.[0-9][0-9].log" -o -iname "*.[0-9][0-9].log.gz" -o -iname "*.[0-9]" -o -iname "*.[0-9].gz" -o -iname "*.[0-9][0-9]" -o -iname "*.[0-9][0-9].gz" \) -exec /bin/rm -f {} \;
Ce qui efface tout fichier log traité par logrotate. Il y a certainement un regex fou qui fait ça en un test. Là, au moins, c’est lisible).
Suivit d’un :
  # find /var/log -type f -exec /bin/cp /dev/null {} \;
qui vide tout fichier log restant
3) Visiter les /tmp pour voir si ils n’ont pas également de gros fichiers
4) Analyser les logs sauvegardés pour voir ce qui a provoquer cet embonpoint…
Si c’est à cause d’un niveau de log trop élevé dans une application (p.e. un niveau « debug » dans Apache ou Samba). Rabaisser le niveau en « info » ou « error » 
Si c’est à cause d’un problème avec un paquet, le résoudre.
5) Si cela a dégagé suffisamment de place, redémarrer le serveur
6) Surveiller le petit comme le lait sur le feu…


Le 22 févr. 2021 à 10:22, Erwann Le Bras <erwann.le-bras@laposte.net> a écrit :


Le 21/02/2021 à 22:10, roger.tarani@free.fr a écrit :
Merci à tous pour vos pistes instructives.

Je découvre qu'il se passe des choses étonnantes en matière de logs dans /var/log/ :

/var/log$ lla -h | grep G
total 7.7G
-rw-r----- 1 root              adm        2.0G Feb 20 19:16 kern.log.1
-rw-r----- 1 root              adm        1.5G Feb 21 00:00 messages.1
-rw-r----- 1 root              adm        1.9G Feb 21 00:00 syslog.1

ça me semble énorme.
1/ Est-ce que je peux supprimer ces fichiers ? (plutôt oui)
2/ Quelle est la manière la plus propre d'éliminer/d'empêcher automatiquement des journaux aussi volumineux ? (je peux utiliser crontab et tester/éliminer fichier plus gros que..)


bonjour

  1. à supprimer, oui, et tous les fichiers compressés au même niveau
  2. en prévention :
    1. Regarder qui loggue quoi et voir pour abaisser le niveau de log si besoin : si ça se trouve un truc loggue inopportunément en mode "debug" ; un vrai pb peut y être remonté et rabaché souvent
    2. paramétrer logrotate pour faire tourner et compresser ces fichier plus rapidement
    3. un "barbu" appréciera un petit script en crontab "hourly" qui envoie un mail ou un sms en cas d'espace disque insuffisant (c-à-d à 80 ou 90% de l'espace occupé) ; un curieux expérimentateur ira regarder du côté de Nagios

amitiés,

--

Erwann Le Bras


-- 
Pierre Malard
Responsable architectures système GeoSUD
IRD - UMR Espace-Dev - UMS CPST
Maison de la Télédétection
500 rue Jean-François Breton
34093 Montpellier Cx 5
France

   « SPAM : Spieced Pork and Meat »
                                       Pierre Dac (Londres, 1944)
Extrait de « Pierre DAC parle au Français » sur Radio Londres, le 24 mars 1944, dans Drôle de guerre, éditions Omnibus (2008), pages 93 à 96. (https://www.epi.asso.fr/revue/articles/a1602d.htm)

   |\      _,,,---,,_
   /,`.-'`'    -.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--

Attachment: signature.asc
Description: Message signed with OpenPGP


Reply to: