Discussion :

[ntrvdonett]

Bonjour,

j'essaye de faire un simple script Bash qui surveille la présence d'un autre script.
Mon idée est de faire une boucle while avec un ps -aux :

Code :

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

1
2
3
4
5
6
7
8
#!/bin/bash
 
while ! ps -auxf | grep "[c]ana.php" > /dev/null 2>&1 ; do
#rien, tu attends !
date >> /home/fichier.log
echo "j'ai rien pour l'instant" >> /home/fichier.log
sleep 5
done

Voilà, ce script fonction parfaitement si je le lance à la main.
Mais lors du boot c'est init qui le lance (je le lance depuis rc.locale)
et là, ps -aux ne sort rien du tout !!

Savez vous pourquoi ? Je me doute qu'il y a quelque chose avec l'environnement mais quoi ?

J'ai fait des recherche sur 'ps' mais je n’aboutis pas !

Merci

[Obsidian]

Hello,

Si tu utilises les options « auxf », je crois qu'il ne faut pas mettre de « - » (syntaxe du ps de BSD).

[ripat]

Tu peux aussi t'éviter le ps | grep grâce à la commande pidof

[N_BaH]

ou pgrep.

mais puisque tu connais le nom exact de la commande, pourquoi pas

Code :

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

1
2
3
4
5
until ps h -C cana.php >/dev/null 2>&1
do 
   date >> ~/fichier.log
   sleep 5
done

?

[jack-ft]

Si tu utilises les options « auxf », je crois qu'il ne faut pas mettre de « - » (syntaxe du ps de BSD).

Effectivement, il faut savoir qu'il y a 2 syntaxes (cf. man ps)... et il faut choisir!
Soit ps -ef (style classique) soit ps aux (style BSD), mais pas 'ps -auxf'!

Il se peut aussi qu'il y ait plusieurs ps sur ta machine. Pour savoir lequel est utilisé par ton script, ajoute 'which ps' au début su script.

Pour ceux qui pourraient s'étonner de voir 'grep "[c]ana.php"' plutôt que le parfaitement équivalent 'grep "cana.php"' , c'est une astuce qui permet d'éviter le 'grep -v grep' (pour filtrer le process qui fait le grep).

Sinon, les réponses utilisant pidof ou pgrep sont plus élégantes... mais probablement moins portables...

[ntrvdonett]

Bonjour,

Désolé pour la réponse tardive,
J'ai essayé

Code :

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

1
2
3
4
5
until ps h -C cana.php >/dev/null 2>&1
do 
   date >> ~/fichier.log
   sleep 5
done

Je n'ai pas le bon fonctionnement avec ça.
d'ailleurs quand je lance en ligne de commande

Code :

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

 ps h -C cana.php

je n'ai pas de sortie. Car je pense que ps réagit plutot à php5 qu'au script php lancé dans la ligne

Code :

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

php5 cana.php

concernant pidof c'est la même chose ça fonctionne avec php5, mais pas

Code :

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

php5 cana.php

du coup si j'ai deux scripts php lancés il n'y a plus de discrimination !

Qu'en pensez vous ?

[N_BaH]

je suis surpris qu'on ne puisse pas mettre php en shebang.

la façon dont est lancé le script, c'est comme si, pour un shell, on le lançait ainsi sh monScript, alors qu'en étant exécutable, et avec un shebang correct (#!/bin/sh) le script est exécuté ainsi <chemin/>monScript.

donc on le retrouve par son nom.

tu peux éditer le script pour lui ajouter un shebang PHP ?

[ripat]

Pourquoi ne mets-tu pas un fichier sémaphore dans ton script php?

Code :

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

1
2
3
4
$flock = '/tmp/php_flock';
file_put_contents($flock, '');
/* ton code php */
unlink($flock);

Tu n'as plus ensuite qu'à tester l'existence du fichier dans ton script shell.

[jlliagre]

Code :

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

1
2
3
4
while ! pgrep -f cana.php; do
    date >> /home/fichier.log
    sleep 5
done

[ntrvdonett]

Oui cette solution apporte de l'eau à mon moulin :

Code :

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

1
2
3
4
while ! pgrep -f cana.php; do
    date >> /home/fichier.log
    sleep 5
done

Par contre il faut ajouter la petite astuce :

Code :

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

while ! pgrep -f [c]ana.php; do

pour éviter d'avoir un retour sur le pgrep lui même, sinon on sortirai du while de toute façon.

Il me reste un petit soucis, lorsque je sors de ma boucle d'attente je dois lancer un script en tant qu'utilisateur Lambda. Mais dans ce cas je suis root. Il faut changer d'utilisateur. Je suppose qu'il faut faire ça avec su Lambda. Il faut un mot de pass ? peut on contourner le mot de pass ?

Merci

[jack-ft]

Il me reste un petit soucis, lorsque je sors de ma boucle d'attente je dois lancer un script en tant qu'utilisateur Lambda. Mais dans ce cas je suis root. Il faut changer d'utilisateur. Je suppose qu'il faut faire ça avec su Lambda. Il faut un mot de pass ? peut on contourner le mot de pass ?

Merci

Lorsqu'un script est exécuté avec root, il bypasse la gestion de droits. Tu peux donc faire le su: il ne demandera pas de mot de passe.

[jlliagre]

Par contre il faut ajouter la petite astuce :

Code :

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

while ! pgrep -f [c]ana.php; do

pour éviter d'avoir un retour sur le pgrep lui même, sinon on sortirai du while de toute façon.

Non, cette petite astuce est inutile car pgrep s'exclut de lui-même de la recherche.

[ntrvdonett]

Merci pour vos réponses.

J'ai fait à la main un

Code :

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

pgrep -f cana.php

et j'ai obtenu deux lignes avec deux numéros de processus différents. Si je refais la commande plusieurs fois, le deuxième numéro évolue, j'en ai conclu que la commande elle même "parasitait" le résultat ?

[jlliagre]

Sous quel OS ?

[ntrvdonett]

Je suis sous Debian Squeeze noyau 3.6.0
Malgré tout la surveillance fonctionne (avec mes petits crochets), je sors de ma boucle mais je souhaite lancer le script de démarrage de DropBox et là rien ! encore
j'ai fait :

Code :

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

1
2
3
su fab >> /home/fab/fichier.log
cd /home/fab/  >> /home/fab/fichier.log
dropbox.py start  >> /home/fab/fichier.log

et soudain, rien ne se passe !

[jlliagre]

Je suis sous Debian Squeeze noyau 3.6.0

Que dit:

Code :

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

1
2
3
4
 
for i in $(pgrep -f cana.php); do
printf "%d : %s\n" $i "$(ps -o command $i | tail -n +2)"
done

?

Malgré tout la surveillance fonctionne (avec mes petits crochets), je sors de ma boucle mais je souhaite lancer le script de démarrage de DropBox et là rien ! encore
j'ai fait :

Code :

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

1
2
3
su fab >> /home/fab/fichier.log
cd /home/fab/  >> /home/fab/fichier.log
dropbox.py start  >> /home/fab/fichier.log

et soudain, rien ne se passe !

Essaie:

Code :

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

su fab -c "cd /home/hab; dropbox.py start" >> /home/fab/fichier.log

[ntrvdonett]

Ok merci pour ta réponse.

J'essaye tout ça lundi.

[disedorgue]

Bonjour,

j'essaye de faire un simple script Bash qui surveille la présence d'un autre script.
Mon idée est de faire une boucle while avec un ps -aux :

Code :

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

1
2
3
4
5
6
7
8
#!/bin/bash
 
while ! ps -auxf | grep "[c]ana.php" > /dev/null 2>&1 ; do
#rien, tu attends !
date >> /home/fichier.log
echo "j'ai rien pour l'instant" >> /home/fichier.log
sleep 5
done

Voilà, ce script fonction parfaitement si je le lance à la main.
Mais lors du boot c'est init qui le lance (je le lance depuis rc.locale)
et là, ps -aux ne sort rien du tout !!

Savez vous pourquoi ? Je me doute qu'il y a quelque chose avec l'environnement mais quoi ?

J'ai fait des recherche sur 'ps' mais je n’aboutis pas !

Merci

Bonjour,

Juste pour préciser que la commande 'ps' à besoin d'avoir un tty de défini car elle formate sa sortie pour celui-ci.
Cela doit être la raison pour laquelle le script fonctionne lorsqu'il est executer à la main mais pas par init.

Cordialement.

[N_BaH]

la commande 'ps' à besoin d'avoir un tty de défini car elle formate sa sortie pour celui-ci.

mais bien sûr, «et la marmotte...»
c'est pour ça que des scripts d'init, tels que udev ou cups, l'utilisent !

[disedorgue]

mais bien sûr, «et la marmotte...»
c'est pour ça que des scripts d'init, tels que udev ou cups, l'utilisent !

Ok, je me trompe certainement (ce n'est pas une rhétorique ironique). Et si quelqu'un a la réponse, je suis preneur.

Personnellement, j'ai déjà eu un cas similaire avec un script qui fonctionnait très bien lorsqu'on le lançait à la main mais qui ne voulait plus fonctionner si on le lançait à distance depuis un ssh. Par contre si on dit à ssh d'allouer un pseudo tty (option -t), là le script fonctionne.

Cordialement.