Bash : interprêtation d'une variable
Résolu
IvyAlice
Messages postés
397
Statut
Membre
-
IvyAlice Messages postés 397 Statut Membre -
IvyAlice Messages postés 397 Statut Membre -
Bonjour à tous,
J'ai un petit soucis avec un plugin nagios que j'ai voulu faire.
Il est sensé regardé si un service tourne sur une machine
Voici le code (j'ai replacé les données sensibles par des étoiles et le nom du proc par <processus>)
le problème c'est $starteret. Lorsque je lance le plugin à la main j'obtiens
y compris si je la lance en su nagios
lorsque nagios le lance, par contre, il m'affiche sur la page de monitoring
il interprète $stateret comme contenant "command" et non pas "OK" quand c'est nagios qui le lance.
Est-ce que quelqu'un aurait une idée ou une explication ?
Merci d'avance,
Ivy
J'ai un petit soucis avec un plugin nagios que j'ai voulu faire.
Il est sensé regardé si un service tourne sur une machine
Voici le code (j'ai replacé les données sensibles par des étoiles et le nom du proc par <processus>)
[code tronqué] # ici si $tmpfile n'existe pas, le pid du processus surveillé est recherché et mis dedans. valpid=$(cat $tmpfile) stringret='/usr/local/nagios/libexec/check_snmp -H * -p * -P * -C * -o hrSWRunPath.$valpid ' stateret='echo $stringret | cut -d' ' -f2' #echo "$stateret" if [ "$stateret" = "OK" ]; then valretour=0 echo "nous sommes dans le stateret = OK --> OUI !!! " else echo "$stateret != OK T_T " fi exit $valretour
le problème c'est $starteret. Lorsque je lance le plugin à la main j'obtiens
nous sommes dans le stateret = OK --> OUI !!!
y compris si je la lance en su nagios
lorsque nagios le lance, par contre, il m'affiche sur la page de monitoring
command != OK T_T
il interprète $stateret comme contenant "command" et non pas "OK" quand c'est nagios qui le lance.
Est-ce que quelqu'un aurait une idée ou une explication ?
Merci d'avance,
Ivy
A voir également:
- Bash : interprêtation d'une variable
- Bingo bash free - Télécharger - Divers Jeux
- Bash pause ✓ - Forum Shell
- Bash addition - Forum Programmation
- Bash permission non accordée - Forum Shell
- Bash list ✓ - Forum Shell
6 réponses
Salut,
stateret='echo $stringret | cut -d' ' -f2'
Si je comprends bien ici tu veux récupérer le résultat de la commande entre apostrophes.
Alors mets soit les apostrophes inverses soit $(commande) , mieux c'est la 2ème possibilités
Et puis si tu veux traiter un apostrophe comme une caractère alors soit tu mets en backslash avant soit tu entoures la chaînes avec des guillemets.
stateret='echo $stringret | cut -d' ' -f2'
Si je comprends bien ici tu veux récupérer le résultat de la commande entre apostrophes.
Alors mets soit les apostrophes inverses soit $(commande) , mieux c'est la 2ème possibilités
Et puis si tu veux traiter un apostrophe comme une caractère alors soit tu mets en backslash avant soit tu entoures la chaînes avec des guillemets.
stateret=$(echo $stringret | cut -d' ' -f2)
Salut lami20j
J'ai essayé ta ligne de commande
Mais j'obtiens toujours le même résultat dans Nagios.
Ivy
J'ai essayé ta ligne de commande
stateret=$(echo $stringret | cut -d' ' -f2)
Mais j'obtiens toujours le même résultat dans Nagios.
Ivy
Re,
Que t'affiche la commande ?
Et dans ta condition if si je ne me trompe pas c'est == (comparaison) et pas = (affectation)
Que t'affiche la commande ?
echo $stateret
Et dans ta condition if si je ne me trompe pas c'est == (comparaison) et pas = (affectation)
Justement si je lance le scripte à la main (en root ou en nagios) $stateret affiche OK et lorsque c'est le processus nagios qui lance le scripte, $stateret affiche command.
je crois que = c'est pour comparer les chaines == pour les nombres
(mais j'ai aussi vu que = c'était pour affecter, cela dépend p-e des espaces laissé ou non de chaque côté, je ne sais pas)
Bref j'ai essayé avec == dans mon if, mais c'est tjr pareil au niveau de la console d'administration. par contre si je lance le scripte manuellement :
(ligne 27 --> c'est le "fi")
je crois que = c'est pour comparer les chaines == pour les nombres
(mais j'ai aussi vu que = c'était pour affecter, cela dépend p-e des espaces laissé ou non de chaque côté, je ne sais pas)
Bref j'ai essayé avec == dans mon if, mais c'est tjr pareil au niveau de la console d'administration. par contre si je lance le scripte manuellement :
root@*:# su nagios ./check_<processus>2.sh [: 27: OK: unexpected operator OK != OK T_T test 3 root@*:# ./check_<processus>.sh nous sommes dans le stateret = OK --> OUI !!!
(ligne 27 --> c'est le "fi")
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Ah ben voilà le problème.
Lorsque Nagios execute la première partie du script :
il me retourne autre chose que quand je lance le script à la main, à savoir "External command error:hrSWRunPath: Unknow Object Identifier (Index out of range:(hrSWRunIndex))
voilà d'où sort la valeur command.
J'dois avoir un pb au niveau snmp alors :-/
(si quelqu'un sait pourquoi snmp ne réagit pas pareil selon si on lance le script à la main ou s'il l'est par nagios, je suis preneuse aussi )
Ivy
Lorsque Nagios execute la première partie du script :
tmpfile='pwd'/check_<processus>_pid.tmp valretour=3 # si le ficheir existe pas met le PID de <processus> dedans [ -f $tmpfile ] || snmpwalk 1*:* -v * -c * -m HOST-RESOURCES-MIB | grep hrSWRunPath | grep <processus>| cut -d. -f 2 | cut -d' ' -f1 > $tmpfile valpid=$(cat $tmpfile) stringret='/usr/local/nagios/libexec/check_snmp -H * -p * -P * -C * -o hrSWRunPath.$valpid '
il me retourne autre chose que quand je lance le script à la main, à savoir "External command error:hrSWRunPath: Unknow Object Identifier (Index out of range:(hrSWRunIndex))
voilà d'où sort la valeur command.
J'dois avoir un pb au niveau snmp alors :-/
(si quelqu'un sait pourquoi snmp ne réagit pas pareil selon si on lance le script à la main ou s'il l'est par nagios, je suis preneuse aussi )
Ivy
Bon je crois que j'ai trouvé le problème.
J'ai remplacé ça
par ça
Et ça marche :-p
Je pense que le demon nagios ne trouvait pas le chemin vers le fichier contenant le pid lorsqu'on le lui donnait de la première façon.
Merci lami20j pour ton aide.
Ivy
J'ai remplacé ça
tmpfile='pwd'/check_<processus>_pid.tmp
par ça
tmpfile="/usr/local/nagios/libexec/others/tests/check_<processus>_pid.tmp"
Et ça marche :-p
Je pense que le demon nagios ne trouvait pas le chemin vers le fichier contenant le pid lorsqu'on le lui donnait de la première façon.
Merci lami20j pour ton aide.
Ivy