Announcement

Collapse
No announcement yet.

"checking for redhat spopen problem"

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

  • "checking for redhat spopen problem"

    Salut tout le monde,

    Je viens de me taper trois installations complètes du système RedHat AS4 et la totale des packages pour avoir Nagios 2.7 et Oreon 1.3.3 et j'ai toujours le même message d'erreur qui interveint durant la phase ./configure de nagios-plugins-1.4.5

    Au bout d'une centaine de checks, j'obtiens le message
    "checking for redhat spopen problem" qui bloque le processus et par conséquent m'empèche d'utiliser les plugins puisque le fichier Utils.pm est absent du répertoire /libexec

    Quelqu'un saurait-il comment se débarasser de ce check ?

    Merci.
    RedHat AS4, Oreon 1.4, Nagios 2.8

  • #2
    Originally posted by Nounours View Post
    Salut tout le monde,

    Je viens de me taper trois installations complètes du système RedHat AS4 et la totale des packages pour avoir Nagios 2.7 et Oreon 1.3.3 et j'ai toujours le même message d'erreur qui interveint durant la phase ./configure de nagios-plugins-1.4.5

    Au bout d'une centaine de checks, j'obtiens le message
    "checking for redhat spopen problem" qui bloque le processus et par conséquent m'empèche d'utiliser les plugins puisque le fichier Utils.pm est absent du répertoire /libexec

    Quelqu'un saurait-il comment se débarasser de ce check ?
    Manifestement, ce serait le check lui-même qui serait en cause car son test est trop restrictif[1].
    Pourquoi ne pas utiliser les paquets RPM[2] officiels (référencés en tant que tels par le projet Nagios) produits par Dag Wieers ?
    Bien qu'il ne dispose pas encore de paquets pour Nagios 2.7 (sorti un peu récemment quand même), je n'arrive pas à comprendre pourquoi vous tenez tant tous à vous passer des paquets binaires (RPM, debian, etc.) qui sont quand même censés fonctionner out-of-a-box... Est-ce parce que vous suivez de trop près les divers HOWTO de qualité variable qu'on trouve avec Google ? Est-ce pour mieux se la péter grave parce qu'on a compilé son Nagios ?

    [1]: http://article.gmane.org/gmane.netwo...s.plugins/1751
    [2]: http://dag.wieers.com/rpm/packages/nagios-plugins/
    Raphaël 'SurcouF' Bordet
    Je ne teste pas mes plugins en root, tu ne testes pas tes plugins en root...
    Dons Paypal

    Comment


    • #3
      +1 mdrrrrr
      Intel(R) Xeon(TM) CPU 3.4GHz - MemTotal : 1034476 kB
      Centreon 2.4.1 - Nagios 3.2.1 - Nagios Plugins 1.4.15 - Manubulon Plugins tuné
      Fedora Core 5 - 2.6.20-1.2320

      Comment


      • #4
        "checking for redhat spopen problem"

        SURCOUF, tu penses vraiment que c'est vouloir se la péter que de vouloir voir ce que fais réellement un package !
        Pour ma part, je préfère me faire chier un peu plus longtemps sur un plantage et essayer d'y venir à bout (seul ou avec un peu d'aide) que de partir sur la solution de facilité (RPM).


        Sinon, pour info j'ai laissé toute la nuit la conf se faire en espérant trouver un message d'erreur au matin...et surprise, la conf s'est terminée. En fait, le test doit boucler un certain temps sur un élément puis permet au traitement de continuer. Le problème est que soit on a une RedHat nickel et passe ce check en 20 secondes, soit il faut au minimum 4 heures pour passer au reste.

        A+
        RedHat AS4, Oreon 1.4, Nagios 2.8

        Comment


        • #5
          Originally posted by Nounours View Post
          SURCOUF, tu penses vraiment que c'est vouloir se la péter que de vouloir voir ce que fais réellement un package !
          Pour ma part, je préfère me faire chier un peu plus longtemps sur un plantage et essayer d'y venir à bout (seul ou avec un peu d'aide) que de partir sur la solution de facilité (RPM).
          Les paquets binaires offrent une solution de "facilité" sur l'installation du logiciel, par sur sa configuration ni son intégration. En outre, ces paquets sont déjà intégrés à la distribution qu'on utilise : il y a moins de risques d'avoir des erreurs qui ne font pas avancer le schmilblick. Maintenant, il faut savoir si le but du jeu est de faire mumuse avec Linux ou d'installer un système de supervision. J'ai la nette impression que pour bon nombre de stagiaires, il y a un peu des deux, voire pas mal du premier.

          Originally posted by Nounours View Post
          Sinon, pour info j'ai laissé toute la nuit la conf se faire en espérant trouver un message d'erreur au matin...et surprise, la conf s'est terminée. En fait, le test doit boucler un certain temps sur un élément puis permet au traitement de continuer. Le problème est que soit on a une RedHat nickel et passe ce check en 20 secondes, soit il faut au minimum 4 heures pour passer au reste.
          En regardant les fichiers .spec qu'utilise Dag Wieers, je n'ai vu aucune mention permettant de contourner ou simplement de mentionner ce problème.
          Il n'existe pas de RedHat plus "nickel" qu'une RHEL fraîchement installée, ce que tu as déjà fait plusieurs fois de suite. La version du noyau sera TOUJOURS la même, or, c'est le traitement de la chaîne de sortie de la commande "uname -r" qui pose problème au configure, rien de plus.
          Pour confirmer, peux-tu nous donner la sortie en question ?
          Raphaël 'SurcouF' Bordet
          Je ne teste pas mes plugins en root, tu ne testes pas tes plugins en root...
          Dons Paypal

          Comment


          • #6
            "checking for redhat spopen problem"

            Mon objectif est tout simplement de comprendre ce que je fais !
            Et sans me la péter, j'espère qu'il y a du monde qui pense comme moi !

            Pour en revenir à la sortie du ./configure, il n'y avait rien de spécifier et a rendu la main comme si le script s'était bien déroulé en 2 mn comme cela aurait dû être le cas.
            RedHat AS4, Oreon 1.4, Nagios 2.8

            Comment


            • #7
              Status de la solution sur RedHat 4

              Salut

              pourrais tu indiquer le "status" de ta solution sur redhat 4.

              Est-ce que tu utilise yum pour maintenir tes packages ou tu installes tout a la mitaine?

              Quels versions utilisses tu?

              Je ne suis pas sur si je dois proceder a deployer la solution avec Redhat 4, Redhat 5, Fedora core 6, Fedora 7. Mes test ont ete fait avec Fedora core 6, mais maintenant il faut que j'installe et je donne une duree de vie d'au moins 24 mois a la solution, alors je dois penser au suport du OS et des packages pour cette periode.

              Comment


              • #8
                Salut,

                Le probleme vient surement de ta configuration DNS (client), verifie la.

                pour les infos un peu plus techniques (même si à première vue ca donne des boutons à certains ) : le script va effectuer une serie de test de nslookup et verifie que ça fait pas d'erreur au niveau du kernel. Cette "faille" est due aux pthreads dans bind.

                En gros tu peux essayer de compiler avec l'option --enable-redhat-pthread-workaround pour sauter cette verif.

                Peut-etre que ca reglera une partie du probleme.
                ..()_() .°("who | grep -i blonde | date; cd ~; unzip;")
                =(o_0)=
                *(() () Nicolas Verriest, France

                Comment

                Working...
                X