Announcement

Collapse
No announcement yet.

snmptrapd qui plante et impossible à redémarrer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • snmptrapd qui plante et impossible à redémarrer

    Je supervise un bon nombre d'hôtes capables d'envoyer des traps snmp et je les réceptionne dans Centreon. Les traps sont de toutes sortes et je n'ai aucun problème à les recevoir, enfin quand snmptrapd est actif

    Après beaucoup de recherches infructueuses, je me tourne vers la communauté Centreon qui m'a beaucoup aidé (sans le savoir ). Voici mon voir mes problèmes:
    • Au bout d'un temps, aléatoire je dirais, snmptrapd plante et mes remontées de traps ne fonctionnent plus. Même si je m'en apperçois, ce qui n'est pas évident puisque je ne passe pas mon temps à verifier si snmptrapd est opérationnel, il m'est impossible de relancer snmptrapd (cmd : /usr/sbin/snmptrapd -Lsd -On -p /var/run/snmptrapd.pid) et je n'ai pas de message d'erreur. Il faut alors que je redémarre ma machine physique et la le service démarre sans problème, mais ce n'est pas idéal.
    Je cherche donc un moyen, soit de ne plus avoir ce plantage dont l'origine m'échappe, soit si vraiment ce n'est pas possible d'avoir quelque chose qui détecte l'absence de snmptrapd et reboot la machine.
    • Mon autre problème vient aussi des traps, cela arrive de temps à autres et je ne sais pas si c'est lié avec le "phénomène" de plantage ci dessus puisque ce n'est pas snmptrapd qui plante mais snmptt qui reste bloqué. En faisant un ps aux | grep snmptt j'obtiens : sh -c (/usr/local/centreon/bin/snmptt --ini=/etc/snmp/centreon_traps/snmptt.ini) < "tmp/snmp/NOM_ALEATOIRE". Pour résoudre ça il suffit de faire un kill -9 du process et les traps reprennent de plus belle.
    Ici mon interrogation est la même, pourquoi est ce que ça arrive et comment résoudre ce problème?

    Merci à ceux qui prendront la peine de me lire et de m'aider,

    Bonne journée.

  • #2
    Originally posted by gordan View Post
    Je supervise un bon nombre d'hôtes capables d'envoyer des traps snmp et je les réceptionne dans Centreon. Les traps sont de toutes sortes et je n'ai aucun problème à les recevoir, enfin quand snmptrapd est actif

    Après beaucoup de recherches infructueuses, je me tourne vers la communauté Centreon qui m'a beaucoup aidé (sans le savoir ). Voici mon voir mes problèmes:
    • Au bout d'un temps, aléatoire je dirais, snmptrapd plante et mes remontées de traps ne fonctionnent plus. Même si je m'en apperçois, ce qui n'est pas évident puisque je ne passe pas mon temps à verifier si snmptrapd est opérationnel, il m'est impossible de relancer snmptrapd (cmd : /usr/sbin/snmptrapd -Lsd -On -p /var/run/snmptrapd.pid) et je n'ai pas de message d'erreur. Il faut alors que je redémarre ma machine physique et la le service démarre sans problème, mais ce n'est pas idéal.
    Je cherche donc un moyen, soit de ne plus avoir ce plantage dont l'origine m'échappe, soit si vraiment ce n'est pas possible d'avoir quelque chose qui détecte l'absence de snmptrapd et reboot la machine.
    • Mon autre problème vient aussi des traps, cela arrive de temps à autres et je ne sais pas si c'est lié avec le "phénomène" de plantage ci dessus puisque ce n'est pas snmptrapd qui plante mais snmptt qui reste bloqué. En faisant un ps aux | grep snmptt j'obtiens : sh -c (/usr/local/centreon/bin/snmptt --ini=/etc/snmp/centreon_traps/snmptt.ini) < "tmp/snmp/NOM_ALEATOIRE". Pour résoudre ça il suffit de faire un kill -9 du process et les traps reprennent de plus belle.
    Ici mon interrogation est la même, pourquoi est ce que ça arrive et comment résoudre ce problème?
    Concernant snmptrapd, il serait intéressant de le démarrer en mode debug afin d'en savoir plus :
    Code:
    # /usr/bin/snmptrapd -On -Lf /tmp/snmptrapd.debug -f -D ALL
    (S'il ne te rend pas la main, c'est normal car j'ai ajouté volontairement l'option -f).
    Lorsque le problème survient à nouveau, essaie de le démarrer via :
    Code:
    # strace -econnect /usr/bin/snmptrapd -Lsd -On -p /var/run/snmptrapd.pid
    Je pense que la socket TCP du port 162 n'a pas été fermée correctement et que, du coup, snmptrapd ne parvient plus à écouter à nouveau sur ce port.
    Pour le valider, demande-lui d'écouter sur un autre port, par exemple le 1162 :
    Code:
    # /usr/sbin/snmptrapd -Lsd -On -p /var/run/snmptrapd.pid <tonadresseIP>:1162
    Quant à SNMPtt, je ne comprends pas cette méthode d'exécution de la part de Centreon. Pourquoi n'utilisent-ils pas le mode démon ? On dirait qu'ils capturent initialement les sorties de snmptrapd (via centTrap-handler ?) pour les renvoyer ensuite vers SNMPtt, le tout via des appels shell couteux... Mais je me trompe peut-être : je ne connais pas la méthode employée.
    Pour SNMPtt, il est également possible d'activer le mode debug via son fichier de configuration principal afin d'en savoir plus.
    Raphaël 'SurcouF' Bordet
    Je ne teste pas mes plugins en root, tu ne testes pas tes plugins en root...
    Dons Paypal

    Comment


    • #3
      Tout d'abord merci beaucoup pour ta réponse rapide.

      Concernant le mode de fonctionnement de snmptt c'est bien en mode démon, en tout cas d'après le fichier d'initialisation. Apparement ce qu'il se passe c'est qu'il doit être en attente d'une modification de mon fichier "/tmp/snmpdW6IqLk" pour transmettre la trap à Centreon. Je ne saurais pas en dire plus, je n'ai aucune idée du code exécuté.

      Pour ce qui est de snmptrapd, merci pour l'information intéressante, j'essayerai de faire tout ce que tu m'as dit.

      Je reposterai un message dès que le problème revient, avec les détails du debug.

      Si d'autres personnes ont des remarques aussi constructives que surcouf, n'hésitez pas.

      Comment


      • #4
        Je viens d'avoir le problème avec snmptt, d'après ce que j'ai pu observer c'est suite à un redémarrage de Nagios après quelques modifications dans la config. Je ne suis toujours pas plus avancé, je vais me lancer dans la lecture de la doc concernant le fonctionnement de snmptt couplé à Centreon. :-o

        Comment

        Working...
        X