Bash script redémarant des process qui meurent

Efhache84 · Le 16/06/2011, à 14:47

Bonjour à tous, j'ai une petite question, je désire faire un script (bash pcq c'est le scripting dispo) qui permettrait de s'assurer qu'une série de process tournent et si jamais l'un d'eux meurt (ou plusieurs) il exécute une série de commande (en réalité d'autres scripts qui permettent de redémarrer les process et de faire une série de test avant redémarage)

J'ai bien une idée de solution avec quelque chose du genre

until myprocess; do
    echo "Process 'myprocess' stopped with exit code $?.  Respawning.." >&2
    sleep 1
done

Mais le désavantage c'est que ça ne fait le suivi que d'un seul et unique process. Je me vois mal faire autant de script que de process à suivre.

Je suis sûr que la solution est idiote, peut-être avec des test et des ou logique. Mais je ne sais comment écrire mon bash pour le faire...
Je bloque sur une bêtise ainsi...

Si quelqu'un peut m'apporter de l'aide, ce serait sympa

EDIT : oui j'ai oublié de dire que avantageusement le unitll loop permet de pas relancer le process si jamais il termine normalement donc sie le retour est 0

Dernière modification par Efhache84 (Le 16/06/2011, à 14:54)

FRUiT · Le 16/06/2011, à 15:53

Peut-être dans ce genre là :

plist="process1 process2 process3"

while :; do
    for proc in $plist; do
        pgrep "$proc" || {
            echo "Respawning $proc"
            eval "$proc"
        }
    done
done

Dernière modification par FRUiT (Le 16/06/2011, à 15:54)

Efhache84 · Le 16/06/2011, à 16:22

Ok je suis peut-être idiot, mais pourquoi mettre ":;" après le while?

cela réalise une sorte de "true" ?

Et sinon probablement qu'il vaut mieux que j'ajoute un sleep d'une dizaine de seconde pour être sûr qu'il ne tourne pas comme un malade dans le script et ainsi être sûr qu'il ne bouffe pas le cpu, non?

EDIT : par contre pgrep n'est pas disponnible, donc je vais utiliser un ps | grep avec un cut ou qqch du genre.

Merci pour la piste, je vais essayer ça

Dernière modification par Efhache84 (Le 16/06/2011, à 16:28)

FRUiT · Le 16/06/2011, à 16:28

Efhache84 a écrit :

Ok je suis peut-être idiot, mais pourquoi mettre ":;" après le while?
cela réalise une sorte de "true" ?

Toutafé, c'est bien ça.

Efhache84 a écrit :

Et sinon probablement qu'il vaut mieux que j'ajoute un sleep d'une dizaine de seconde pour être sûr qu'il ne tourne pas comme un malade dans le script et ainsi être sûr qu'il ne bouffe pas le cpu, non?

Certes ! C'est juste un petit exemple de structure.

Efhache84 · Le 17/06/2011, à 08:32

Juste une petite aide encore avec mon remplacement de pgrep...

imaginons un process qui s'appelle webcommanager.

ps | grep webcommanager

me renvoit

root@ptxblackbox:~ ps | grep webcommanager
  159 root       7684 R   ./webcommanager
  172 root       7684 S   ./webcommanager
  174 root       7684 S   ./webcommanager
  447 root       2052 S   grep webcommanager

si je complète avec un cut et quelques infos... j'obtiens juste le nom... malheureusement plusieurs fois puisque ps répertorie chaque threat de ce process ainsi que l'utilisation de grep

ainsi

ps | grep webcommanager | cut -d'/' -f2

me donne presque ce que je désire :

root@ptxblackbox:~ ps | grep webcommanager | cut -d'/' -f2
webcommanager
webcommanager
webcommanager
  454 root       2052 S   grep webcommanager

mais maitenant comment faire pour n'obtenir que la première ligne de ce résultat ? puisque je cherche à remplacer pgrep...

Dernière modification par Efhache84 (Le 17/06/2011, à 08:33)

FRUiT · Le 17/06/2011, à 10:28

Déjà, un petit trux pour ne pas avoir grep dans les résultats :

ps | grep "[w]ebcommanager"

Avec une variable, ça peut donner :

proc="[w]ebcommanager"
ps | grep $proc

Ensuite pour le problème, personnellement je ferais :

ps | awk 'BEGIN { FS="/" } /[w]ebcommanager/ { print $2 ; exit }'

Ou, avec variable :

ps | awk 'BEGIN { FS="/" } /'"$proc"'/ { print $2 ; exit }'

Efhache84 · Le 17/06/2011, à 10:32

ah je ne connaissais pas awk, voila qqch de nouveau. merci beaucoup ;-)

FRUiT · Le 17/06/2011, à 10:36

Awk remplace avantageusement (selon moi) cut, grep, wc, sed; etc... Il sait tout faire et c'est quasiment un langage de programmation.

Efhache84 · Le 17/06/2011, à 10:41

sans doute ai-je fait une bêtise mais le comportement du script est assez étonnant

cd /pcsfolder
plist="[w]ebcommanager [l]cddrive"

while :; do
    for proc in $plist; do
    ps | awk 'BEGIN { FS="/" } /'"$proc"'/ { print $2 ; exit }' || {
        echo "Respawning $proc"
        eval "$proc"
        }
    done
    sleep 10
done

et à l'éxécution du script j'obtiens :

root@ptxblackbox:~ ./watchdog_script
  }
  }

donc une accolade apparaissant toutes les 10 secondes, mais aucun des process n'est démarré... je ne suis pas spécialiste du script bash donc il y a sûrement une erreur dans ce que j'ai écrit mais je ne la trouve pas.

FRUiT · Le 17/06/2011, à 12:54

Tout d'abord eval ne pourra pas relancer le process avec les crochets.

Pour les enlever avant d'exécuter tu peux faire :

rproc="${proc//[][]/}"
eval "${rproc}"

Ensuite avec awk traitant le ps, même si aucun résultat n'est trouvé le code de sortie reste 0, donc le test n'est plus valide. Il faudra faire quelque chose du genre :

rproc=$(ps | awk 'BEGIN { FS="/" } /'"$proc"'/ { print $2 ; exit }')
[ "${rproc}" ] || {
    eval "${rproc}"
}

Ce qui résoudra le problème des crochets en même temps.

Mais bon je suis pas sûr qui ait pas plus simple comme méthode c'était une idée comme ça. Peut-être d'autres auront de meilleures idées.

Dernière modification par FRUiT (Le 17/06/2011, à 12:55)

AnsuzPeorth · Le 17/06/2011, à 13:21

Bjr,
Un exemple pour firefox:

if ! ps aux | grep -q /firefox-bin; then firefox; fi

La commande ps seul ne sort rien d'exploitable chez moi (en console en tout cas).

C'est une autre façon de voir

EDIT: Pour éviter un pipe

if ! grep -q /firefox-bin < <(ps aux); then firefox; fi

EDIT2:
Ca devrait donner un truc du genre, si la sortie de ps est comme indiqué plus haut

cd /pcsfolder
plist="webcommanager lcddrive"

while :; do
    # peut être pas besoin de lancer un ps pour chaque exe à checker ?
    data_ps=$(ps)
    for proc in ${plist}; do
        if ! grep -q /${proc} <<< "${data_ps}"; then
           #pas besoin de eval ! Et les commandes ne devraient pas être lancé en arrière plan ?
           ${proc} &
        fi
    done
    sleep 10
done

EDIT3:
pfff, j'en ai des choses à dire
Je connais pas tes softs, mais si ils gardent la main, et que tu veux qu'il tournent tous le temps, pourquoi ne pas faire simplement un script qui lance tes commandes dès le départ, et les relancer dès qu'elle rendent la main. Au besoin, créer un fichier dans tmp pour arrêter la boucle.
Il n'y aura aucune commande ou autre sleep.
genre:

Webcom()
{
webcommanager
Webcom
}
Lcddrive()
{
lcddrive
Lcddrive
}
Webcom &
Lcddrive &

Dernière modification par AnsuzPeorth (Le 17/06/2011, à 14:07)

Efhache84 · Le 17/06/2011, à 15:20

AnsuzPeorth a écrit :

(...)

cd /pcsfolder
plist="webcommanager lcddrive"

while :; do
    # peut être pas besoin de lancer un ps pour chaque exe à checker ?
    data_ps=$(ps)
    for proc in ${plist}; do
        if ! grep -q /${proc} <<< "${data_ps}"; then
           #pas besoin de eval ! Et les commandes ne devraient pas être lancé en arrière plan ?
           ${proc} &
        fi
    done
    sleep 10
done

Elle seront lancé tel quel

start-stop-daemon -S -b -x ./webcommanager

AnsuzPeorth a écrit :

(...)
EDIT3:
pfff, j'en ai des choses à dire
Je connais pas tes softs, mais si ils gardent la main, et que tu veux qu'il tournent tous le temps, pourquoi ne pas faire simplement un script qui lance tes commandes dès le départ, et les relancer dès qu'elle rendent la main. Au besoin, créer un fichier dans tmp pour arrêter la boucle.
Il n'y aura aucune commande ou autre sleep.
genre:
Webcom()
{
webcommanager
Webcom
}
Lcddrive()
{
lcddrive
Lcddrive
}
Webcom &
Lcddrive &

Actuellement un script pour les lancer contient une série de start-stop-daemon comme montré ci-dessus.

Jusque là tout va bien, mais je veux me prémunir contre les arrêts éventuels de process. Donc ici l'idée serait de toujours les lancer par un script mais de faire une sorte de monitoring qui va vérifier qu'ils sont toujours actif comme process et sinon les relancer.

Eventuellement par une tâche cron... comme autre option ?

J'en suis aux essais et réflexion pour l'instant. L'idée est d'essayer de faire ça avec une souplesse script et de ne pas s'amuser à écrire un soft watchdog...
Donc je suis ouvert à toute idée.

Dernière modification par Efhache84 (Le 17/06/2011, à 15:21)

AnsuzPeorth · Le 17/06/2011, à 16:01

As tu vraiment besoin de strat-daemon pour ça ?

Si tu ne fais que lancer des process, sans avoir besoin de tout les possibilités de ce soft, un simple bash suffirait !

Il faut savoir, si ce que tu lances garde la main ou pas. Si ca garde, pas besoin de tester, suffit de relancer la commande en cas de sortie non souhaité.
Pour arrêter, suffit de kill le script (selon les commandes, peut être utiliser exec, ou tuer les fils, à voir !)

SuiteDeCommande1()
{
tes commandes qui gardent la main
}

SuiteDeCommande2()
{
tes commandes qui gardent la main
}

Main1()
{ #tu peux aussi utiliser start-daemon, mais sans l'option -b, pour ne pas forcer l'arrière plan
SuiteDeCommande1
Main1
}
Main2()
{
SuiteDeCommande2
Main2
}
Main1 &
Main2 &

Dernière modification par AnsuzPeorth (Le 17/06/2011, à 16:03)

FRUiT · Le 17/06/2011, à 16:46

AnsuzPeorth a écrit :

SuiteDeCommande1()
{
tes commandes qui gardent la main
}

Y'a un trux que je m'explique pas... Si la suite de commandes c'est UNE commande je vois le principe, mais si y"en a plusieurs ? Je veux bien un petit éclaircissement...

Dernière modification par FRUiT (Le 17/06/2011, à 16:47)

AnsuzPeorth · Le 17/06/2011, à 17:05

FRUiT a écrit :

AnsuzPeorth a écrit :
SuiteDeCommande1()
{
tes commandes qui gardent la main
}
Y'a un trux que je m'explique pas... Si la suite de commandes c'est UNE commande je vois le principe, mais si y"en a plusieurs ? Je veux bien un petit éclaircissement...

J'aurais du noter tes commandes dont la dernière garde la main, effectivement, mal exprimé (mais c'est une sorte d'algo qui est montré, pas un code complet ). Et puis on ne sait pas quelles commandes sont utilisées ? Donc ca revient à avancer dans le noir !

Si on veut lancer toutes les commandes de la fonction en arrière plan, mais garder la fonction en premier plan, un petit wait fera l'affaire. (mais je pense que tu le sais déjà )

SuiteDeCommande1()
{
cmd1 &
cmd2 &
cmd3 &
wait
}

Je trouve plus interessant de se servir de ce principe que de faire une boucle infini !
On peut très bien lancer des scripts plutot que des fonctions, c'était pour l'exemple.

Dernière modification par AnsuzPeorth (Le 17/06/2011, à 17:23)

FRUiT · Le 17/06/2011, à 17:55

Oki c'est plus clair merci ^^

Finalement c'est quand même une sorte de boucle infinie aussi :

Main2()
{
SuiteDeCommande2
Main2
}

Construite différemment certes.

En fait si j'ai bien compris il y aurait quasiment autant de fonctions/scripts (et boucles) qu'il n'y aurait de processus à relancer ? Faut voir combien ça fait de processus à traiter en tout, mais là c'est vrai qu'on avance un peu dans le noir, peut-être que plus de précisions ne feraient pas de mal...

AnsuzPeorth · Le 17/06/2011, à 18:04

Ben d'après ses exemples, 2 processus (2 scripts qui gardent la main, sinon l'option -b ne serait pas renseigner); il suffit de mettre le contenu des scripts dans des fonctions.
C'est vrai que c'est le principe d'une boucle, mais sans sleep ou controle avec ps & co (encore mal exprimé .:rolleyes:)

Dernière modification par AnsuzPeorth (Le 17/06/2011, à 18:07)

Efhache84 · Le 20/06/2011, à 08:01

Petites précisions.

Actuellement je possède un script qui ne fait que lancer une série d'éxécutable (process écrit en C), ils sont lancés comme décrit ci-dessus.
La liste des process à lancer (et qui restent actifs) peut varier au cours du temps. (il peut y en avoir plus ou moins donc)

En fait je veux simplement m'assurer avec une solution simple et flexible que les process tournent et si l'un d'eux ne tourne plus qu'il soit simplement relancé (ou si cela est finalement plus simple, si l'un d'eux meurt, on coupe tout et on relance toute la lsite de process)

Dernière modification par Efhache84 (Le 20/06/2011, à 08:01)

FRUiT · Le 20/06/2011, à 10:10

Efhache84 a écrit :

lancer une série d'éxécutable

Oui mais..... Combien ? En moyenne ? ...2 ? ...20 ? ...200 ?

AnsuzPeorth · Le 20/06/2011, à 10:23

Ce n'est donc pas le script qu'il faut surveiller, mais les process qu'il lance. Ca change tout
Donc ma façon de voir ne sera pas bonne.

Efhache84 · Le 20/06/2011, à 11:24

FRUiT a écrit :

Efhache84 a écrit :
lancer une série d'éxécutable
Oui mais..... Combien ? En moyenne ? ...2 ? ...20 ? ...200 ?

une quinzaine

en effet ce n'est pas un script qu'il faut surveiller mais bien les process qui sont lancés.

maintenant peut-être que je me trompe en imaginant que ce serait surveillable par script

AnsuzPeorth · Le 20/06/2011, à 12:29

maintenant peut-être que je me trompe en imaginant que ce serait surveillable par script

Ben en faisant une boucle, comme proposé plus haut.

FRUiT · Le 20/06/2011, à 13:35

FRUiT a écrit :

Tout d'abord eval ne pourra pas relancer le process avec les crochets.
Pour les enlever avant d'exécuter tu peux faire :
rproc="${proc//[][]/}"
eval "${rproc}"
Ensuite avec awk traitant le ps, même si aucun résultat n'est trouvé le code de sortie reste 0, donc le test n'est plus valide. Il faudra faire quelque chose du genre :
rproc=$(ps | awk 'BEGIN { FS="/" } /'"$proc"'/ { print $2 ; exit }')
[ "${rproc}" ] || {
    eval "${rproc}"
}
Ce qui résoudra le problème des crochets en même temps.
Mais bon je suis pas sûr qui ait pas plus simple comme méthode c'était une idée comme ça. Peut-être d'autres auront de meilleures idées.

Ouais bon en fait plutôt que d'utiliser des crochets génants pour relancer les commandes, ou s'em....er avec awk ou des grep -q, ps -C c'est mieux. Et puis ça peut être bien de détacher les processus du scrit en question histoire que si il plante ou est arrêté, les processus continuent de s'exécuter. Donc, tu peux surement faire :

plist="webcommanager process2 process3"
for proc in $plist; do
    ps -C $proc || nohup $proc &
done

Dernière modification par FRUiT (Le 20/06/2011, à 15:13)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 16/06/2011, à 14:47

Bash script redémarant des process qui meurent

#2 Le 16/06/2011, à 15:53

Re : Bash script redémarant des process qui meurent

#3 Le 16/06/2011, à 16:22

Re : Bash script redémarant des process qui meurent

#4 Le 16/06/2011, à 16:28

Re : Bash script redémarant des process qui meurent

#5 Le 17/06/2011, à 08:32

Re : Bash script redémarant des process qui meurent

#6 Le 17/06/2011, à 10:28

Re : Bash script redémarant des process qui meurent

#7 Le 17/06/2011, à 10:32

Re : Bash script redémarant des process qui meurent

#8 Le 17/06/2011, à 10:36

Re : Bash script redémarant des process qui meurent

#9 Le 17/06/2011, à 10:41

Re : Bash script redémarant des process qui meurent

#10 Le 17/06/2011, à 12:54

Re : Bash script redémarant des process qui meurent

#11 Le 17/06/2011, à 13:21

Re : Bash script redémarant des process qui meurent

#12 Le 17/06/2011, à 15:20

Re : Bash script redémarant des process qui meurent

#13 Le 17/06/2011, à 16:01

Re : Bash script redémarant des process qui meurent

#14 Le 17/06/2011, à 16:46

Re : Bash script redémarant des process qui meurent

#15 Le 17/06/2011, à 17:05

Re : Bash script redémarant des process qui meurent

#16 Le 17/06/2011, à 17:55

Re : Bash script redémarant des process qui meurent

#17 Le 17/06/2011, à 18:04

Re : Bash script redémarant des process qui meurent

#18 Le 20/06/2011, à 08:01

Re : Bash script redémarant des process qui meurent

#19 Le 20/06/2011, à 10:10

Re : Bash script redémarant des process qui meurent

#20 Le 20/06/2011, à 10:23

Re : Bash script redémarant des process qui meurent

#21 Le 20/06/2011, à 11:24

Re : Bash script redémarant des process qui meurent

#22 Le 20/06/2011, à 12:29

Re : Bash script redémarant des process qui meurent

#23 Le 20/06/2011, à 13:35

Re : Bash script redémarant des process qui meurent

Pied de page des forums