Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Bash script redémarant des process qui meurent

Efhache84

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

FRUiT

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

Efhache84

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

FRUiT

Efhache84 a écritOk 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 écritEt 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

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...

FRUiT

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

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

FRUiT

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

Efhache84

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

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.

AnsuzPeorth

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 &

Efhache84

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.

AnsuzPeorth

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 &

FRUiT

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...

AnsuzPeorth

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à :rolleyes: )

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.

FRUiT

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

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:)

Efhache84

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)

FRUiT

Efhache84 a écritlancer une série d'éxécutable

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

AnsuzPeorth

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.

Page suivante »