Anomalie #5577
Eole 2.3 : Erreurs zephiragents dans le syslog
Description
Bonjour,
je constate que les fichiers "/var/log/syslog" et "/var/log/rsyslog/local/zephiragents/zephiragents/alert.log" de nos serveurs Horus et Scribe 2.3 se remplissent environ toutes les 8 minutes avec les messages suivants :
Jun 12 16:34:18 horus zephiragents: [-] Unhandled error in Deferred:
Jun 12 16:34:18 horus zephiragents: [-] Unhandled Error
Jun 12 16:34:18 horus zephiragents: [-] #011Traceback (most recent call last):
Jun 12 16:34:18 horus zephiragents: [-] #011Failure: twisted.internet.error.ProcessTerminated: A process has ended with a probable error condition: process ended with exit code 1.
Jun 12 16:34:18 horus zephiragents: [-] Unhandled error in Deferred:
Jun 12 16:34:18 horus zephiragents: [-] Unhandled Error
Jun 12 16:34:18 horus zephiragents: [-] #011Traceback (most recent call last):
Jun 12 16:34:18 horus zephiragents: [-] #011Failure: twisted.internet.error.ProcessTerminated: A process has ended with a probable error condition: process ended with exit code 1.
Les serveurs sont à jour, le diagnose est OK.
Demandes liées
Révisions associées
corrections sur la gestion des retour des scripts de mesures (agents eximstats et bacula)
Fixes #5577Corrections sur les agents de surveillance
- correction d'appels systèmes (données sur stderr pour printers, ...)
- amélioration des logs en cas d'erreur de mesure
Fixes #5577 @4h
Historique
#1 Mis à jour par Joël Cuissinat il y a plus de 10 ans
- Projet changé de Horus à zephir-client
- Statut changé de Nouveau à A étudier
- Assigné à mis à Bruno Boiget
- Version cible mis à Mises à jour 2.3.12
#2 Mis à jour par Bruno Boiget il y a environ 10 ans
- Distribution changé de EOLE 2.3 à Toutes
Le problème semble venir de l'agent eximstats.
Il utilise le script /usr/sbin/eximstat.sh mais celui-ci renvoie un message sur la sortie d'erreur si il ne trouve pas de logs à traiter (l'agent attend ce message sur la sortie standard).
-−> utiliser aussi le callback de l'appel à eximstats.sh comme errback (et gérer le cas ou le retour est de type 'failure')
#3 Mis à jour par Bruno Boiget il y a environ 10 ans
pour gérer ce genre de cas (informations utiles remontées sur stderr), il est possible d'utiliser 'errortoo=1' avec la commande getProcessOutput pour ne pas avoir d'errback dès que la sortie d'erreur est utilisée.
ex dans ce cas :
res = getProcessOutput("/usr/share/zephir/monitor/bin/eximstats.sh", env = {'LC_ALL': 'C'}, errortoo=1)
#4 Mis à jour par Bruno Boiget il y a environ 10 ans
- Statut changé de A étudier à Résolu
- % réalisé changé de 0 à 100
Appliqué par commit 3febaa23786e95e6642b9e343bb75a20b3cbba75.
#5 Mis à jour par Fabrice Barconnière il y a environ 10 ans
- Statut changé de Résolu à À valider
- % réalisé changé de 100 à 90
Toujours les messages dans les logs toute les 6 à 8 minutes.
#6 Mis à jour par Fabrice Barconnière il y a environ 10 ans
- Version cible changé de Mises à jour 2.3.12 à Mises à jour 2.3.13
#7 Mis à jour par Bruno Boiget il y a presque 10 ans
- Temps estimé mis à 2.50 h
Les agents suivants font des appels via getProcessOutput sans gérer le cas d'une sortie en erreur:
diag.py
netstat.py
samba3.py
services.py
systeme.py
web.py
#8 Mis à jour par Bruno Boiget il y a presque 10 ans
- Echéance mis à 16/05/2014
#9 Mis à jour par Bruno Boiget il y a presque 10 ans
Après modification dans la librairie process.py de twisted pour afficher le processus en erreur sur un serveur :
May 12 17:28:40 serv-pedago zephiragents: [-] #011Traceback (most recent call last): May 12 17:28:40 serv-pedago zephiragents: [-] #011Failure: twisted.internet.error.ProcessTerminated: A process has ended with a probable error condition: process (/usr/share/zephir/monitor/bin/printers.sh) ended with exit code 1.
Le problème vient de l'appel à la commande lpstat qui renvoie un message sur la sortie d'erreur dans le cas ou aucune imprimante n'est déclarée:
/usr/bin/lpstat -p lpstat: Aucune destination ajoutée.
Il y a pourtant bien un 'errback' ajouté à l'appel du script, mais il ne semble pas pris en compte dans ce cas.
En utilisant errortoo=1 ici aussi, on passe dans le callback dans tous les cas (même si le code de retour n'est pas 0 ...)
#10 Mis à jour par Bruno Boiget il y a presque 10 ans
- Statut changé de À valider à Résolu
- % réalisé changé de 90 à 100
Appliqué par commit ec4d00cef6eab160b9f694962b4e56cdf67e9154.