logs ne tournent pas comme demandé

kbvz · Le 06/07/2021, à 09:23

Bonjour,

j'ai du rater qqch:

- j'ai un log qui grossit un peu vite, dans l'attente de résoudre ce qui le fait grossir, je voudrais limiter sa taille et le faire tourner quand sa taille est critique.
J'ai un peu fouillé mais j'ai une question: est ce qu'il tourne dès qu'il atteins le seuil critique ou il doit attendre le passage d'un cronjob ?

j'ai laissé le cron en dailly et ai rajouté en hourly:

#!/bin/sh

/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit $EXITVALUE

et voici le fichier de conf rapport au log concerné:

/var/log/squid/cache.log {
    daily
    rotate 2
    dateext
    size 5G
    compress
    notifempty
    missingok
    nocreate
    sharedscripts
    postrotate
      # Asks squid to reopen its logs. (logfile_rotate 0 is set in squid.conf)
      # errors redirected to make it silent if squid is not running
      /usr/sbin/squid -k rotate 2>/dev/null
      # Wait a little to allow Squid to catch up before the logs is compressed
      sleep 1
    endscript
}

Malgré cela j'ai (ls -lah):

-rw-r-----   1 squid squid 8.3G Jul  6 09:23 cache.log

Qu'est ce que j'ai raté ?

Merci

Dernière modification par kbvz (Le 06/07/2021, à 09:23)

geole · Le 06/07/2021, à 09:58

Bonjour
Il serait préférable de commencer par en chercher la cause car la rectification peut ne pas être immédiate
Merci de donner ce retour

journalctl -b -p err | tail -200 >Trace.txt && xdg-open Trace.txt

Avant de manquer de place disque, tu devrais tout simplement ne pas produire les log!!!!!
Voir Paragraphe 4.6 de https://doc.ubuntu-fr.org/ssd_solid_sta … u_logiciel

Dernière modification par geole (Le 06/07/2021, à 09:59)

kbvz · Le 06/07/2021, à 10:18

Salut

oui tu as raison mais je voudrais aussi limiter la taille des logs

la seconde partie des commandes ne passe pas voici le contenu de l'extract

-- Logs begin at Mon 2021-07-05 19:16:01 CEST, end at Tue 2021-07-06 10:16:51 CEST. --
Jul 06 08:49:52 l-adm-proxy-01r systemd[3871457]: pam_sss(systemd-user:session): Request to sssd failed. Connection refused
Jul 06 08:49:53 l-adm-proxy-01r sshd[3871454]: pam_sss(sshd:session): Request to sssd failed. Connection refused
Jul 06 10:06:18 l-adm-proxy-01r sshd[3874812]: pam_sss(sshd:session): Request to sssd failed. Connection refused

geole · Le 06/07/2021, à 11:48

Donnes ce retour

journalctl --no-pager -b -p err

Pour la limitation, A adapter à ton souhait

sudo journalctl --vacuum-size=1G  --vacuum-time=7d –vacuum-files=10
systemctl restart systemd-journald

kbvz · Le 06/07/2021, à 12:54

voici

journalctl --no-pager -b -p err
-- Logs begin at Mon 2021-07-05 22:06:28 CEST, end at Tue 2021-07-06 12:54:24 CEST. --
Jul 06 08:49:52 l-adm-proxy-01r systemd[3871457]: pam_sss(systemd-user:session): Request to sssd failed. Connection refused
Jul 06 08:49:53 l-adm-proxy-01r sshd[3871454]: pam_sss(sshd:session): Request to sssd failed. Connection refused
Jul 06 10:06:18 l-adm-proxy-01r sshd[3874812]: pam_sss(sshd:session): Request to sssd failed. Connection refused
Jul 06 10:17:28 l-adm-proxy-01r sshd[3908554]: pam_sss(sshd:session): Request to sssd failed. Connection refused
Jul 06 11:35:39 l-adm-proxy-01r sshd[3871454]: pam_sss(sshd:session): Request to sssd failed. Connection refused
Jul 06 11:43:19 l-adm-proxy-01r sshd[3908554]: pam_sss(sshd:session): Request to sssd failed. Connection refused
Jul 06 12:19:01 l-adm-proxy-01r sshd[3913541]: pam_sss(sshd:session): Request to sssd failed. Connection refused

geole · Le 06/07/2021, à 12:58

C'est loin d'être volumineux.....
Pour confirmation

journalctl  --no-pager  --since  "2021-07-06 09:00" --until  "2021-07-06 12:00"

Nuliel · Le 06/07/2021, à 13:01

Bonjour,
Pour l'erreur rencontrée, tu peux regarder dans la conf de sshd (/etc/ssh/sshd_config) et voir si UsePAM est à yes ou no.

bruno · Le 06/07/2021, à 13:03

Bonjour,

Je ne vois pas bien l’utilité des commandes proposées par geole, mais il doit avoir ses raisons…

Ton fichier de configuration est correct et le fichier de log subira bien une rotation si la taille est supérieure à 5 Go, sachant que logrotate n'est appelé qu'une fois par jour via /etc/cron.daily

Ce que tu observes est donc normal : le fichier peut continuer à grossir tant que la tâche cron n'est pas exécutée.

Comme le dit geole, il faut trouver la cause du problème plutôt qu'essayer des bidouillages sur les fichiers de logs. Donc, à voir du côté de la configuration de squid pour voir si ces logs sont utiles ou peuvent être rendus moins bavards.

Regarde notamment cette réponse :
https://www.fixya.com/support/t422657-s … ver_geting

--
@Nulliel : les erreurs renvoyées par journalctl concernent probablement LDAP ou autre (pam-sss) mais pas SSH (tentatives de connexion avortées)
Je considère que c'est un problème totalement indépendant de la question initiale.

Dernière modification par bruno (Le 06/07/2021, à 13:08)

kbvz · Le 06/07/2021, à 13:35

geole a écrit :

C'est loin d'être volumineux.....
Pour confirmation
journalctl  --no-pager  --since  "2021-07-06 09:00" --until  "2021-07-06 12:00" 

J'ai cette erreur en boucle (77000 lignes) ..

/autogen/155/_00002.wal: no space left on device"
Jul 06 11:59:59 l-adm-proxy-01r influxd[370271]: ts=2021-07-06T09:59:59.307114Z lvl=info msg="Cache snapshot (start)" log_id=0U3x0P5W000 engine=tsm1 trace_id=0VAo~vIl000 op_name=tsm1_cache_snapshot op_event=start
Jul 06 11:59:59 l-adm-proxy-01r influxd[370271]: ts=2021-07-06T09:59:59.307167Z lvl=info msg="Cache snapshot (end)" log_id=0U3x0P5W000 engine=tsm1 trace_id=0VAo~vIl000 op_name=tsm1_cache_snapshot op_event=end op_elapsed=0.061ms
Jul 06 11:59:59 l-adm-proxy-01r influxd[370271]: ts=2021-07-06T09:59:59.307184Z lvl=info msg="Error writing snapshot" log_id=0U3x0P5W000 engine=tsm1 error="error opening new segment file for wal (1): write /var/lib/influxdb/wal/influx_db/autogen/149/_00002.wal: no space left on device"

bruno · Le 06/07/2021, à 13:45

Cela commence à faire beaucoup de problème qui s'accumulent et concernent des services différents. Maintenant c'est influxdb…
Il va falloir décrire ta configuration : type de serveur (dédié, vps, machine locale,…), version d'Ubuntu utilisée et les services actif sur ce serveur.
Tout ceci pourra être utile :

lsb_release -a

systemctl list-units --type=service --no-pager

df -Th

kbvz · Le 06/07/2021, à 13:52

bruno a écrit :

Bonjour,
Je ne vois pas bien l’utilité des commandes proposées par geole, mais il doit avoir ses raisons…
Ton fichier de configuration est correct et le fichier de log subira bien une rotation si la taille est supérieure à 5 Go, sachant que logrotate n'est appelé qu'une fois par jour via /etc/cron.daily
Ce que tu observes est donc normal : le fichier peut continuer à grossir tant que la tâche cron n'est pas exécutée.
Comme le dit geole, il faut trouver la cause du problème plutôt qu'essayer des bidouillages sur les fichiers de logs. Donc, à voir du côté de la configuration de squid pour voir si ces logs sont utiles ou peuvent être rendus moins bavards.
Regarde notamment cette réponse :
https://www.fixya.com/support/t422657-s … ver_geting
--
@Nulliel : les erreurs renvoyées par journalctl concernent probablement LDAP ou autre (pam-sss) mais pas SSH (tentatives de connexion avortées)
Je considère que c'est un problème totalement indépendant de la question initiale.

En fait, meme en forcant le logrotate il me refoule, j'ai donc enlevé le parametre dateex et c''est passé.. je vais rester en survaillance.

J'ai aussi mis le cronjob en hourly et il en tournait pas.
je vais regarder les erreurs

geole · Le 06/07/2021, à 14:03

Je t'ai donné un lien qui évite d'écrire en DOUBLE exemplaire dans le répertoire que tu veux compresser. J'ai préféré mettre un lien plutôt que les commandes car il est possible que, pour un serveur, cela ne soit pas identique. Sinon c'est

sudo cp -v  /etc/rsyslog.d/50-default.conf /etc/rsyslog.d/50-default.conf.REF
sudo sed -i 's/*.*;auth,authpriv.none/###########   *.*;auth,authpriv.none/' /etc/rsyslog.d/50-default.conf
sudo sed -i 's/kern./###########   kern./' /etc/rsyslog.d/50-default.conf

Le journal lui-même sait s'auto-limiter à 4 Go voir moins si tu changes son paramétrage

Dernière modification par geole (Le 06/07/2021, à 14:04)

bruno · Le 06/07/2021, à 14:26

@geole : en général je donne le conseil inverse : ne pas laisser journald écrire dans /var/log/journal Je considère cette doc comme mauvaise, ou en tout cas totalement inadaptée à un serveur. Il y a des tas d'arguments pour l'un ou l'autre système de logs mais il faut ouvrir un autre fil pour en débattre.

geole · Le 06/07/2021, à 15:03

Bruno. Chacun son avis
Lorsque d'un coté on a un log qui s'auto limite à 4 Go avec une commande journalctl de recherche
et de l'autre une logique débile qui relit ce fichier pour l'éclater dans d'autres fichiers ( en veux-tu en voila) , jusqu'à empêcher un ordinateur de mettre en route lorsqu'il y a tellement de fichiers y compris compressés aboutissant à consommer 100% de l'espace et qui sont quasiment inconsultables sur place puisque undézippable car plus de place disque, je pense que le choix est vite fait.
C'est pour cela je n'ai pas répondu à la demande de création d'un crontab horaire qui complique encore le problème et que j'ai proposé de déactiver le doublonnage de cette façon.

Bien entendu, Lorsque le serveur est à 100 lieues, on peut aussi rapatrier le répertoire journal et le consulter de son propre ordinateur. Ce n'est probablement pas plus compliqué que rapatrier les divers syslog et kern.log

J'avais vu quelque part que cette double production était restée à cause des serveurs.

Dernière modification par geole (Le 06/07/2021, à 15:11)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 06/07/2021, à 09:23

logs ne tournent pas comme demandé

#2 Le 06/07/2021, à 09:58

Re : logs ne tournent pas comme demandé

#3 Le 06/07/2021, à 10:18

Re : logs ne tournent pas comme demandé

#4 Le 06/07/2021, à 11:48

Re : logs ne tournent pas comme demandé

#5 Le 06/07/2021, à 12:54

Re : logs ne tournent pas comme demandé

#6 Le 06/07/2021, à 12:58

Re : logs ne tournent pas comme demandé

#7 Le 06/07/2021, à 13:01

Re : logs ne tournent pas comme demandé

#8 Le 06/07/2021, à 13:03

Re : logs ne tournent pas comme demandé

#9 Le 06/07/2021, à 13:35

Re : logs ne tournent pas comme demandé

#10 Le 06/07/2021, à 13:45

Re : logs ne tournent pas comme demandé

#11 Le 06/07/2021, à 13:52

Re : logs ne tournent pas comme demandé

#12 Le 06/07/2021, à 14:03

Re : logs ne tournent pas comme demandé

#13 Le 06/07/2021, à 14:26

Re : logs ne tournent pas comme demandé

#14 Le 06/07/2021, à 15:03

Re : logs ne tournent pas comme demandé

Pied de page des forums