Petite question concernant les logs de TGW (logs distantes) :
Je n’ai peut être pas vu / trouvé, mais comment faire pour effacer les logs d’une antenne distante ???
En effaçant les logs de Jeedom, le fichier tgw_# revient à la prochaine « synchro », et 180Mo de logs ca fait mal pour le pauvre jeedom (au départ j’avais activé les logs en debug, mais theengs est très bavard… ensuite j’ai remis en « warning » via le plugin TGW mais cela n’a pas vidé le fichier de logs)
J’ai fini par résoudre mon problème, en allant sur l’antenne distante, j’ai vidé le fichier de log (au niveau Linux) de Theensgs Gateway et du coup maintenant cela va mieux.
Peut être (si ce n’est pas déjà fait) prévoir une manière d’effacer les logs distantes ?
un truncate -s 0 /var/log/TheengsGateway.log lancé à distance (soit via un bouton dans l’équipement, soit automatiquement par exemple lors d’un changement de niveau de logs dans la conf, donc à l’install/reinstall d’une antenne)
Ensuite,
peut-être travailler avec le « logrotate » sur l’antenne distante (à mettre en place à l’install de l’antenne, soit par jour, soit par taille pour éviter que cela ne grimpe de trop au fil du temps.
A la première installation via TGW, j’avais mis les logs en niveau « Debug » dans la config de l’antenne distante (ce que je déconseille, car hyper verbeux…) et du coup j’ai laissé ca tourner 24h, en passant sur autre chose, et dans ce mode Theengs log tous les messages BT, et ca finit par faire bcp quand ca tourne 24h
Ensuite je suis repassé en niveau de logs « Warning » pour Theengs, mais c’est là que j’ai vu que le fichier de logs ne disparaissait pas.
Après avoir fait le « ménage » sur l’antenne distante, je te confirme que depuis, mon fichier de log reste désespérément vide (ce qui est une très bonne chose qu’il reste vide, je plaisante sur le « désespérément » )
alors des tests que je suis en train de faire depuis ce matin (car avant j’avais pas réactivé les modes verbeux sur l’antenne, donc le fichier de logs était à 0 donc forcément tout allait bien !), la réponse rapide est « non », voici maintenant pourquoi :
La conf logrotate est bien là, pas de soucis pour TheengsGateway. Mais par défaut, logrotate est configuré pour ne tourner qu’une seule fois par jour (cron daily), et si on active le mode verbeux de l’antenne (en passant en « debug », ce qui je le rappelle n’est PAS conseillé), le fichier de log grossit beaucoup trop vite pour attendre la nuit d’après pour se vider (là en quelques heures, il a atteint les 280Mo, je l’ai vidé à la main du coup pour éviter de faire tomber le jeedom qui récupérait ces logs derrière…)
Pour palier à cela, peut être qu’il faudrait rajouter un cron hourly pour logrotate ? et / ou ajouter un bouton dans le plugin pour tronquer les logs à la main en cas « d’urgence ».
Pour l’instant, j’ai repassé les logs en level « info » (il se remplit plus doucement) sur l’antenne pour voir si cette nuit le logrotate passera bien dessus.
A dispo pour faire d’autres tests si besoin,
TiTidom.
Mips déconseille de passer en mode debug les logs car c’est justement trop bavard. Il conseille le niveau info (et encore en cas de problème : sinon pourquoi ?).
Edit : j’ai lu trop vite que tu précisais déjà ce point.
Oui, je suis bien d’accord, (et c’est pour ca que je redis dans mon message que ce n’est pas conseillé de passer en debug ).
Là c’était pour tester le logrotate que je suis repassé en debug, pour être sûr que le fichier de log se remplisse rapidement et dépasse les seuils définis dans le fichier de conf que Mips pousse via son plugin pour le logrotate
Moi je lis : ça fonctionne
C’est juste, que cela ne convient pas pour un usage inapproprié.
Je pense qu’l faut laisser ainsi. Car, il est possible d’imaginer qu’un autre mode de verbosité que Debug puisse avoir besoin de 24 heures et pas d’une seule heure.
Oui je suis bien au courant que par défaut la rotation n’a lieu qu’une fois par jour et je suis contre modifier son cron, ca pourrait avoir un impact sur autre chose sur le système distant, le plugin ne contrôle pas tout ce qui est installé.
La purge à la main je n’aime pas non plus, par contre je peux rajouter une commande sur l’équipement pour exécuter logrotate manuellement (en suivant la config faite), ca sera une commande du style:
sudo logrotate /etc/logrotate.d/TheengsGateway
ainsi en mode debug, la personne a les cartes en main pour gérer et ca reste dans l’esprit du plugin de pouvoir gérer l’antenne depuis jeedom.
Si je lance cette commande à la main, elle retourne une erreur pour ma part (sous Ubuntu 22.04 là où est installé l’antenne)
error: skipping "/var/log/TheengsGateway.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
mais c’est bien d’avoir des retours aussi, ca permet de confronter les idées
après il faut effectivement trouver une solution la plus équilibrée possible, le but n’est pas non plus de tout proposer et d’arriver à un plugin difficile à gérer ou maintenir tellement qu’il y a d’options
Voici comme convenu un retour sur le logrotate de cette nuit :
La partie logrotate s’est effectivement exécutée, mais il y a un soucis ensuite car le fichier de log reste vide : (la capture a été faite ce matin vers 7h30)
Après redémarrage du service TheengsGateway, les logs se remplissent à nouveau normalement :
Quelques suggestions pour contourner ce problème :
utiliser l’instruction « copytruncate » au niveau du logrotate de TheengsGateway
utiliser le postrotate avec l’instruction de redémarrage du service TheengsGateway (ou envoyer un sighup au service)
l’inconvénient de la 2ème option, c’est que du coup il y a une notification comme quoi l’antenne est down qui va arriver côté Jeedom à chaque fois que le logrotate tourne.
ok bizarre que l’antenne n’écrit plus dans le nouveau log (enfin j’imagine la raison ca oui, le service à garder son pointeur vers l’ancien fichier probablement) mais ce qui est bizarre ce que je n’ai pas le même comportement
(au départ j’avais activé les logs en debug, mais theengs est très bavard… ensuite j’ai remis en « warning » via le plugin TGW mais cela n’a pas vidé le fichier de logs)
)
