Discussion :

[bedomon]

Bonjour tout le monde,

Voila j'ai un petit script pour qui vérifie l’existence de demons et en fonction du status, j'exporte une variable que je voudrais récupérer par un autre programme.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
SERVICE='java'
SERVICE2='frontalbox frontaladmin frontalvisu server-control-message activemq'
 
DATE=$(date +%Y/%m/%d-%H:%M:%S)
 
for serv_name in $SERVICE2 ; do
	if ps ax | grep -v grep | grep $SERVICE | grep $serv_name > /dev/null
	then
		echo "$serv_name service running, everything is fine"
		if [ "$serv_name" = "server-control-message" ]
		then
			serv_name='server_control_message'
		fi
		export $serv_name='ok'
	else
		if [ "$serv_name" = "server-control-message" ]
		then
			serv_name='server_control_message'
		fi
		export $serv_name='nok'
    	        echo "$serv_name is not running! $DATE" | mail -s "$serv_name down" root
	fi
	echo "$serv_name"
done

le petit if au milieu de la boucle est la car on ne peux pas avoir de tiret dans les noms de variable d'environnment.
Le problème avec ce script est que le echo à la fin m'affiche le nom de la variable $serv_name au lien de sa valeur...

Quelqu'un aurait il une idée ?

Merci d'avance

[disedorgue]

Bonjour,

Retire les $ sur le nom de ta variable dans les ligne export:
on fait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export variable="..."

pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export $variable="..."

Si cela ne corrige pas tout, on y verra plus clair...

[N_BaH]

Bonjour,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

declare $serv_name='ok'

, car il est bien question de déclarer une variable.

quelques petites choses :

• ps -C "$serv_name", ou pgrep "$serv_name" plutôt que la chaîne de greps.
• un tableau pour une liste plutôt qu'une variable
• les noms des variables d'un script, pour éviter des collisions avec les variables d'environnement, doivent ne pas être tout en majuscules.
• puisque le if est le même, il serait plus judicieux de le placer avant le test d'"existence" du "démon".

et n'oublie pas de mettre un shebang bash.

[bedomon]

Merci disedorgue, ca m'affiche bien la valeur.


Pour le pgrep j'avais vu cette commande, le problème c'est que le nom de la commande est java et je veux le nom du jar derrière, c'est pour ca que je l'ai fais comme ca et avec ps -C je n'ai pas le nom du jar dans la sortie de la commande.

Sinon pour le declare, je vois ce que cela apporte, mais je ne vois pas l'intéret puisque dansle man il est marqué :

When used in a function, declare makes each name local, as with the local command.

donc ma variable est lié au script, une fois fini, elle n'existe plus... et moi je veux qu'elle vive même après le script...
Je suis clair ?

[disedorgue]

Pas tout compris de ce que tu voulais faire par rapport à ton script.
J'ai rectifié mon post précédent, car je pensais que N_BaH était plus dans le vrai dans ce que tu voulais faire.

Dans ton script, tu utilises la même variable pour tout.
les if au milieu ne servent strictement à rien si tu as retirer les $ sur les lignes export.

[N_BaH]

ma variable est lié au script, une fois fini, elle n'existe plus

de toutes façons, les variables d'un script n'existent que dans ce script, elles ne peuvent pas affecter le processus parent; à moins de l'y sourcer.

dansle man il est marqué :

When used in a function, declare makes each name local, as with the local command.

ce n'est pas le cas ici.

si tu veux afficher, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

frontalbox ok

, tu dois effectivement utiliser des noms de variables différents, pour le service et pour l'état.

ou alors, avec une indirection :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ service=Service_01
$ declare $service=ok
$ echo "$service = ${!service}"
Service_01 = ok

sinon, il faut connaître le nom de la variable :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ echo "Service_01 = ${Service_01}"
Service_01 = ok

[bedomon]

Ok je pense comprendre,

Alors le pourquoi du comment de mon script :

j'ai un JMS qui tourne avec activemq, ainsi que plusieurs "module" java (lancer en tant que service) indépendants les uns des autres (et qui communique entre eux via JMS) pour recevoir et traités les messages.
D'un autre coté il y a une appli web (php-stomp) par laquelle des utilisateurs peuvent effectuer des actions et ces actions sont répercuter via JMS sur les modules java et des équipements électriques.

Le but de mon script qui sera exécuté toutes les 5 minutes est de tester les services java, et de mettre leur état dans un variable d'environnement qui sera lu par l'appli php et en fonction de l'état des services j’empêche les modifications dans les ihm. (j'ai essayer d'autres méthodes et pour moi celle ci est le meilleur compromis entre performance et conso de ressource)

Concernant la portée des variables, j'ai oublié de préciser qu'elles sont instancier dans mon .bashrc, mais la modification de la valeur ne dure que le temps du script.

donc si j'ai bien compris il faut que je déclare autant de variable que de service à tester, ou alors avec avec le principe d'indirection je peux utiliser les même variable dans une boucle du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
for a in $SERVICE2 ; do
    service=$a
    declare $a=OK
done

j'ai l'impression que je ne suis pas très clair

Concernant mon if redondant c'est a cause de la commande export qui ne veux pas de tiret dans le nom de la variable

[N_BaH]

mon script qui sera exécuté toutes les 5 minutes[...]Concernant la portée des variables, j'ai oublié de préciser qu'elles sont instancier dans mon .bashrc

euh, ça va pas être possible : bashrc est lu une fois lors de l'ouverture de la session utilisateur.

[bedomon]

Donc même si mes variables sont dans le bashrc et que je l'ai modifie, impossible de conserver la modification hors du script

Moi qui pensait avoir une solution à peu près viable... Je suis vraiment frusté...

Quand tu évoque de sourcé le fichier, ca serais quelque chose du genre :

je fais mon script, je redirige dans un fichier les commande export et je "source" le fichier ?

[bedomon]

Bon je sais pas si je dois mettre résolu, puisque le mot de la fin est pas possible...

[N_BaH]

je sais pas si je dois mettre résolu, puisque le mot de la fin est pas possible...

ton problème est-il résolu ?

àmha, c'est au moment où l'utilisateur accède à l'interface (ou lors du rafraîchissement de celle-ci) que le test devrait être effectué; et, ce, donc, par le code php (peut-il le faire par lui-même ? a-t-il besoin de commandes externes ? comment php va-t-il utiliser le retour ?)
...
?

[jack-ft]

Alors le pourquoi du comment de mon script :

j'ai un JMS qui tourne avec activemq, ainsi que plusieurs "module" java (lancer en tant que service) indépendants les uns des autres (et qui communique entre eux via JMS) pour recevoir et traités les messages.
D'un autre coté il y a une appli web (php-stomp) par laquelle des utilisateurs peuvent effectuer des actions et ces actions sont répercuter via JMS sur les modules java et des équipements électriques.

Le but de mon script qui sera exécuté toutes les 5 minutes est de tester les services java, et de mettre leur état dans un variable d'environnement qui sera lu par l'appli php et en fonction de l'état des services j’empêche les modifications dans les ihm. (j'ai essayer d'autres méthodes et pour moi celle ci est le meilleur compromis entre performance et conso de ressource)

Ne serait-il pas plus logique de faire un service "récapitulatif" qui teste les services java toutes les 5 minutes et enregistre (en ram dans des variables locales) l'état des services. L'appli php interrogerait le service récapitulatif pour connaître l'état des services et inhiber les modifications.
Sous réserve que l'interrogation du service récapitulatif soit plus efficace que l'interrogation des services évidemment...
Sinon il "suffit" de mettre ces variables locales en mémoire partagée avec l'appli php!

[Sve@r]

Donc même si mes variables sont dans le bashrc et que je l'ai modifie, impossible de conserver la modification hors du script

Salut
Oui. Tout script est exécuté dans un nouveau processus créé lors de l'appel du script. Et dans ce processus fils (car issu d'un "parent"), tout est totalement isolé.
Les éléments d'un père peuvent être recopié dans le fils à sa création (rôle de "export") mais les éléments d'un fils ne peuvent jamais remonter vers le père.

Quand tu évoque de sourcé le fichier, ca serais quelque chose du genre :

je fais mon script, je redirige dans un fichier les commande export et je "source" le fichier ?

sourcer un script (exécuté par la commande source fichier) revient à recopier le contenu du script à cet endroit puis à exécuter les lignes du script tout comme si ces lignes étaient réellement écrites. Je ne sais pas si cela peut t'aider surtout si l'appli qui doit traiter ces variables est lancée avant que les variables soient crées dans l'environnement. Parce que cette appli (elle aussi processus fils) a déjà récupéré son environnement lorsqu'elle s'est initialisée et n'ira jamais en chercher un autre...

Le but de mon script qui sera exécuté toutes les 5 minutes est de tester les services java, et de mettre leur état dans un variable d'environnement qui sera lu par l'appli php et en fonction de l'état des services j’empêche les modifications dans les ihm. (j'ai essayer d'autres méthodes et pour moi celle ci est le meilleur compromis entre performance et conso de ressource)

Tu es dans la problématique générale du transfert d'informations entre différents processus.
C'est une problématique car les processus sont naturellement isolés les uns des autres. Maintenant tu as quand-même des possibilités. Par exemple tu peux utiliser des fichiers, des pipes, une bdd sqlite, tu peux faire appel aux msq Unix, bref tu as des outils. Mais passer par l'environnement est à mon avis infaisable...

[bedomon]

Merci pour vos réponses,

je vais me repencher sur mon problème dans quelque jours et je vous tiens au courant, des petites urgences sont arrivées entre temps.

[bedomon]

Une solution à été trouvé mais elle n'a rien a voir avec le problème de départ. On a géré le problème directement dans les applications, et en fonction des exceptions qui sont lancés ont envoie des messages à un serveur jms qui attendra que les applications soient relancé ( un autre message jms est envoyé pour dire qu'ils sont repartis)


Voila merci à vous tous car dans tous les cas, vous avez éclairer mes connaissances sur le bash