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.
Related issues
Associated revisions
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
History
#1 Updated by Joël Cuissinat over 9 years ago
- Project changed from Horus to zephir-client
- Status changed from Nouveau to A étudier
- Assigned To set to Bruno Boiget
- Target version set to Mises à jour 2.3.12
#2 Updated by Bruno Boiget about 9 years ago
- Distribution changed from EOLE 2.3 to 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 Updated by Bruno Boiget about 9 years ago
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 Updated by Bruno Boiget about 9 years ago
- Status changed from A étudier to Résolu
- % Done changed from 0 to 100
Appliqué par commit 3febaa23786e95e6642b9e343bb75a20b3cbba75.
#5 Updated by Fabrice Barconnière about 9 years ago
- Status changed from Résolu to À valider
- % Done changed from 100 to 90
Toujours les messages dans les logs toute les 6 à 8 minutes.
#6 Updated by Fabrice Barconnière about 9 years ago
- Target version changed from Mises à jour 2.3.12 to Mises à jour 2.3.13
#7 Updated by Bruno Boiget almost 9 years ago
- Estimated time set to 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 Updated by Bruno Boiget almost 9 years ago
- Due date set to 05/16/2014
#9 Updated by Bruno Boiget almost 9 years ago
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 Updated by Bruno Boiget almost 9 years ago
- Status changed from À valider to Résolu
- % Done changed from 90 to 100
Appliqué par commit ec4d00cef6eab160b9f694962b4e56cdf67e9154.