Bonjour,
J'ai beau cherché un peu partout, mais comme la question est un poil
difficile a bien exprimer en anglais, je ne trouve pas de réponse
satisfaisante sur Google. Voici le probleme :
J'ai un programme qui se lance en shell et dont je veux etre sur qu'il
soit toujours lancé, meme s'il plante. Je cherche donc une commande qui
surveille ce processus et le relance via le script s'il se termine.
J'aimerai ne pas passer par une commande (ps | grep ) car il me semble
que sous Fedora Core 3 il existe qq chose de plus intuitif.
Merci.
PS: sous Fedora toujours, il me semble qu'il existe un systeme de
monitoring de gateway internet et qui peut basculer vers un systeme de
secours en cas de defaillance (si on a 2 passerelles), mais impossible
de remettre la main sur la doc. Un lien ?
( Fri, 07 Jan 2005 16:32:27 +0100 ) Eric Delcamp :
Bonjour,
Bonjour
J'ai un programme qui se lance en shell et dont je veux etre sur qu'il soit toujours lancé, meme s'il plante.
??!
- Si il plante, il peut encore etre listé dans les processes actifs, donc inutile, voire impossible de le relancer (par exemple si il bind un port)
- Un process qui a planté ne devrais pas etre relancé sans qu'on aie identifié la cause du plantage. Sinon c'est le bordel. Et toi, tu veux forcer le relancement aveuglément. C'est mal.
Je cherche donc une commande qui surveille ce processus et le relance via le script s'il se termine.
- Si un programme quelconque plante, ben il ne peut pas envoyer un signal du genre "SIGPLANTE" puisqu'il est planté. Il n'existe donc en general aucun moyen de savoir si un process a planté sauf si disparait de la liste des processes actifs.
- Evidemment, si il s'est auto-killé, alors c'est plus simple. -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
( Fri, 07 Jan 2005 16:32:27 +0100 ) Eric Delcamp :
Bonjour,
Bonjour
J'ai un programme qui se lance en shell et dont je veux etre sur qu'il
soit toujours lancé, meme s'il plante.
??!
- Si il plante, il peut encore etre listé dans les processes actifs, donc
inutile, voire impossible de le relancer (par exemple si il bind un port)
- Un process qui a planté ne devrais pas etre relancé sans qu'on aie
identifié la cause du plantage. Sinon c'est le bordel. Et toi, tu veux
forcer le relancement aveuglément. C'est mal.
Je cherche donc une commande qui
surveille ce processus et le relance via le script s'il se termine.
- Si un programme quelconque plante, ben il ne peut pas envoyer un signal
du genre "SIGPLANTE" puisqu'il est planté. Il n'existe donc en general
aucun moyen de savoir si un process a planté sauf si disparait de la
liste des processes actifs.
- Evidemment, si il s'est auto-killé, alors c'est plus simple.
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
( Fri, 07 Jan 2005 16:32:27 +0100 ) Eric Delcamp :
Bonjour,
Bonjour
J'ai un programme qui se lance en shell et dont je veux etre sur qu'il soit toujours lancé, meme s'il plante.
??!
- Si il plante, il peut encore etre listé dans les processes actifs, donc inutile, voire impossible de le relancer (par exemple si il bind un port)
- Un process qui a planté ne devrais pas etre relancé sans qu'on aie identifié la cause du plantage. Sinon c'est le bordel. Et toi, tu veux forcer le relancement aveuglément. C'est mal.
Je cherche donc une commande qui surveille ce processus et le relance via le script s'il se termine.
- Si un programme quelconque plante, ben il ne peut pas envoyer un signal du genre "SIGPLANTE" puisqu'il est planté. Il n'existe donc en general aucun moyen de savoir si un process a planté sauf si disparait de la liste des processes actifs.
- Evidemment, si il s'est auto-killé, alors c'est plus simple. -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
John Mackerel
Eric Delcamp wrote:
J'ai un programme qui se lance en shell et dont je veux etre sur qu'il soit toujours lancé, meme s'il plante. Je cherche donc une commande qui surveille ce processus et le relance via le script s'il se termine.
http://cr.yp.to/daemontools.html
Eric Delcamp wrote:
J'ai un programme qui se lance en shell et dont je veux etre sur qu'il
soit toujours lancé, meme s'il plante. Je cherche donc une commande qui
surveille ce processus et le relance via le script s'il se termine.
J'ai un programme qui se lance en shell et dont je veux etre sur qu'il soit toujours lancé, meme s'il plante. Je cherche donc une commande qui surveille ce processus et le relance via le script s'il se termine.
http://cr.yp.to/daemontools.html
Nicolas George
R12y wrote in message :
- Si un programme quelconque plante, ben il ne peut pas envoyer un signal du genre "SIGPLANTE" puisqu'il est planté. Il n'existe donc en general aucun moyen de savoir si un process a planté sauf si disparait de la liste des processes actifs.
Si : il envoit un SIGCHLD (ou plutôt le noyau le fait) à son père.
Donc un bête
while true; do script done
ferait l'affaire.
Mais je suis d'accord avec toi : la priorité numéro 1 est d'identifier la cause du plantage et de la corriger.
R12y wrote in message <pan.2005.01.07.15.48.30.170803@mail.rktmb.org>:
- Si un programme quelconque plante, ben il ne peut pas envoyer un signal
du genre "SIGPLANTE" puisqu'il est planté. Il n'existe donc en general
aucun moyen de savoir si un process a planté sauf si disparait de la
liste des processes actifs.
Si : il envoit un SIGCHLD (ou plutôt le noyau le fait) à son père.
Donc un bête
while true; do
script
done
ferait l'affaire.
Mais je suis d'accord avec toi : la priorité numéro 1 est d'identifier la
cause du plantage et de la corriger.
- Si un programme quelconque plante, ben il ne peut pas envoyer un signal du genre "SIGPLANTE" puisqu'il est planté. Il n'existe donc en general aucun moyen de savoir si un process a planté sauf si disparait de la liste des processes actifs.
Si : il envoit un SIGCHLD (ou plutôt le noyau le fait) à son père.
Donc un bête
while true; do script done
ferait l'affaire.
Mais je suis d'accord avec toi : la priorité numéro 1 est d'identifier la cause du plantage et de la corriger.
l'indien
On Fri, 07 Jan 2005 16:48:31 +0100, Rakotomandimby (R12y) Mihamina wrote:
( Fri, 07 Jan 2005 16:32:27 +0100 ) Eric Delcamp :
Bonjour,
Bonjour
J'ai un programme qui se lance en shell et dont je veux etre sur qu'il soit toujours lancé, meme s'il plante.
??!
- Si il plante, il peut encore etre listé dans les processes actifs, donc inutile, voire impossible de le relancer (par exemple si il bind un port)
Non. Quand un process reçoit un signal qui le tue, il devient zombie. Il est impossible qu'il reste actif. Il est possible que le programme trappe le signal mais dans ce cas ... il ne plante pas ! Le seul cas ou le process reste listé "actif" c'est quand il est executé par un debuggeur (en fait quand un autre process, généralement son père, a activé le mode ptrace). C'est le seul cas ou un plantage ne libère pas les ressources.
- Un process qui a planté ne devrais pas etre relancé sans qu'on aie identifié la cause du plantage. Sinon c'est le bordel. Et toi, tu veux forcer le relancement aveuglément. C'est mal.
C'est très juste...
Je cherche donc une commande qui surveille ce processus et le relance via le script s'il se termine.
- Si un programme quelconque plante, ben il ne peut pas envoyer un signal du genre "SIGPLANTE" puisqu'il est planté. Il n'existe donc en general aucun moyen de savoir si un process a planté sauf si disparait de la liste des processes actifs.
Bien sur que si. Il y a deux façons de s'en sortir: - le programme trappe tous les signaux qui le tue par défaut (sauf SIGKILL puisque c'est impossible ;-) ) et lorsqu'il reçoit ce signal, soit se relance lui même, soit envoie un signal pré-défini (généralement SIGHUP) à son père pour lui dire de tout réinitialiser. - le programme crashe tout bêtement et son père reçoit alors un SIGCHLD du noyau. Mais même s'il pour une raison quelconque il ne le recevait pas, il suffit de faire de temps en temps des waitpid en mode non bloquant pour savoir qu'un process fils s'est terminé: c'est souvent implémenté comme celà car les signaux Unix ont la facheuse tendance à se déclencher quand il ne faudrait pas et il est plus simple de poller un état que de prévoir un programme complètement asynchrone.
Il y a, sur toutes les machines Linux, un process expréssément dédié à cette tâche, et uniquement à celà: init ! La méthode standard pour qu'un daemon soit géré et relancé automatiquement, c'est de le mettre en mode "respawn" dans l'inittab pour les runlevels ou il doit tourner. C'est extrèmement simple et sur de marcher.
- Evidemment, si il s'est auto-killé, alors c'est plus simple.
Non. C'est exactement la même chose.
On Fri, 07 Jan 2005 16:48:31 +0100, Rakotomandimby (R12y) Mihamina wrote:
( Fri, 07 Jan 2005 16:32:27 +0100 ) Eric Delcamp :
Bonjour,
Bonjour
J'ai un programme qui se lance en shell et dont je veux etre sur qu'il
soit toujours lancé, meme s'il plante.
??!
- Si il plante, il peut encore etre listé dans les processes actifs, donc
inutile, voire impossible de le relancer (par exemple si il bind un port)
Non. Quand un process reçoit un signal qui le tue, il devient zombie. Il
est impossible qu'il reste actif. Il est possible que le programme trappe
le signal mais dans ce cas ... il ne plante pas ! Le seul cas ou le
process reste listé "actif" c'est quand il est executé par un debuggeur
(en fait quand un autre process, généralement son père, a activé le
mode ptrace). C'est le seul cas ou un plantage ne libère pas les
ressources.
- Un process qui a planté ne devrais pas etre relancé sans qu'on aie
identifié la cause du plantage. Sinon c'est le bordel. Et toi, tu veux
forcer le relancement aveuglément. C'est mal.
C'est très juste...
Je cherche donc une commande qui
surveille ce processus et le relance via le script s'il se termine.
- Si un programme quelconque plante, ben il ne peut pas envoyer un signal
du genre "SIGPLANTE" puisqu'il est planté. Il n'existe donc en general
aucun moyen de savoir si un process a planté sauf si disparait de la
liste des processes actifs.
Bien sur que si. Il y a deux façons de s'en sortir:
- le programme trappe tous les signaux qui le tue par défaut (sauf
SIGKILL puisque c'est impossible ;-) ) et lorsqu'il reçoit ce signal,
soit se relance lui même, soit envoie un signal pré-défini
(généralement SIGHUP) à son père pour lui dire de tout réinitialiser.
- le programme crashe tout bêtement et son père reçoit alors un SIGCHLD
du noyau. Mais même s'il pour une raison quelconque il ne le recevait
pas, il suffit de faire de temps en temps des waitpid en mode non bloquant
pour savoir qu'un process fils s'est terminé: c'est souvent implémenté
comme celà car les signaux Unix ont la facheuse tendance à se
déclencher quand il ne faudrait pas et il est plus simple de poller un
état que de prévoir un programme complètement asynchrone.
Il y a, sur toutes les machines Linux, un process expréssément dédié
à cette tâche, et uniquement à celà: init !
La méthode standard pour qu'un daemon soit géré et relancé
automatiquement, c'est de le mettre en mode "respawn" dans l'inittab pour
les runlevels ou il doit tourner. C'est extrèmement simple et sur de
marcher.
- Evidemment, si il s'est auto-killé, alors c'est plus simple.
On Fri, 07 Jan 2005 16:48:31 +0100, Rakotomandimby (R12y) Mihamina wrote:
( Fri, 07 Jan 2005 16:32:27 +0100 ) Eric Delcamp :
Bonjour,
Bonjour
J'ai un programme qui se lance en shell et dont je veux etre sur qu'il soit toujours lancé, meme s'il plante.
??!
- Si il plante, il peut encore etre listé dans les processes actifs, donc inutile, voire impossible de le relancer (par exemple si il bind un port)
Non. Quand un process reçoit un signal qui le tue, il devient zombie. Il est impossible qu'il reste actif. Il est possible que le programme trappe le signal mais dans ce cas ... il ne plante pas ! Le seul cas ou le process reste listé "actif" c'est quand il est executé par un debuggeur (en fait quand un autre process, généralement son père, a activé le mode ptrace). C'est le seul cas ou un plantage ne libère pas les ressources.
- Un process qui a planté ne devrais pas etre relancé sans qu'on aie identifié la cause du plantage. Sinon c'est le bordel. Et toi, tu veux forcer le relancement aveuglément. C'est mal.
C'est très juste...
Je cherche donc une commande qui surveille ce processus et le relance via le script s'il se termine.
- Si un programme quelconque plante, ben il ne peut pas envoyer un signal du genre "SIGPLANTE" puisqu'il est planté. Il n'existe donc en general aucun moyen de savoir si un process a planté sauf si disparait de la liste des processes actifs.
Bien sur que si. Il y a deux façons de s'en sortir: - le programme trappe tous les signaux qui le tue par défaut (sauf SIGKILL puisque c'est impossible ;-) ) et lorsqu'il reçoit ce signal, soit se relance lui même, soit envoie un signal pré-défini (généralement SIGHUP) à son père pour lui dire de tout réinitialiser. - le programme crashe tout bêtement et son père reçoit alors un SIGCHLD du noyau. Mais même s'il pour une raison quelconque il ne le recevait pas, il suffit de faire de temps en temps des waitpid en mode non bloquant pour savoir qu'un process fils s'est terminé: c'est souvent implémenté comme celà car les signaux Unix ont la facheuse tendance à se déclencher quand il ne faudrait pas et il est plus simple de poller un état que de prévoir un programme complètement asynchrone.
Il y a, sur toutes les machines Linux, un process expréssément dédié à cette tâche, et uniquement à celà: init ! La méthode standard pour qu'un daemon soit géré et relancé automatiquement, c'est de le mettre en mode "respawn" dans l'inittab pour les runlevels ou il doit tourner. C'est extrèmement simple et sur de marcher.
- Evidemment, si il s'est auto-killé, alors c'est plus simple.
Non. C'est exactement la même chose.
Nicolas George
l'indien wrote in message :
- Si il plante, il peut encore etre listé dans les processes actifs, donc inutile, voire impossible de le relancer (par exemple si il bind un port) Non. Quand un process reçoit un signal qui le tue, il devient zombie. Il
est impossible qu'il reste actif. Il est possible que le programme trappe le signal mais dans ce cas ... il ne plante pas !
Ça dépend ce qu'on entend par planter. Un processus qui est parti dans une boucle infinie à attendre des données sur un fd fermé ou une connerie comme ça, on peut raisonnablement dire qu'il est planté. Mais rien ne permet génériquement de le déterminer¹. La solution consiste alors à avoir un processus qui surveille si le service qui est censé être assuré l'est effectivement.
Mais bien sûr, la bonne solution est de supprimer l'origine du plantage.
1 : démonstration : soit un test universel de plantage d'un processus, alors j'écris un démon qui fait son travail si et seulement si le test signale qu'il est planté.
l'indien wrote in message <pan.2005.01.08.00.13.50.351752@magic.fr>:
- Si il plante, il peut encore etre listé dans les processes actifs, donc
inutile, voire impossible de le relancer (par exemple si il bind un port)
Non. Quand un process reçoit un signal qui le tue, il devient zombie. Il
est impossible qu'il reste actif. Il est possible que le programme trappe
le signal mais dans ce cas ... il ne plante pas !
Ça dépend ce qu'on entend par planter. Un processus qui est parti dans une
boucle infinie à attendre des données sur un fd fermé ou une connerie comme
ça, on peut raisonnablement dire qu'il est planté. Mais rien ne permet
génériquement de le déterminer¹. La solution consiste alors à avoir un
processus qui surveille si le service qui est censé être assuré l'est
effectivement.
Mais bien sûr, la bonne solution est de supprimer l'origine du plantage.
1 : démonstration : soit un test universel de plantage d'un processus, alors
j'écris un démon qui fait son travail si et seulement si le test signale
qu'il est planté.
- Si il plante, il peut encore etre listé dans les processes actifs, donc inutile, voire impossible de le relancer (par exemple si il bind un port) Non. Quand un process reçoit un signal qui le tue, il devient zombie. Il
est impossible qu'il reste actif. Il est possible que le programme trappe le signal mais dans ce cas ... il ne plante pas !
Ça dépend ce qu'on entend par planter. Un processus qui est parti dans une boucle infinie à attendre des données sur un fd fermé ou une connerie comme ça, on peut raisonnablement dire qu'il est planté. Mais rien ne permet génériquement de le déterminer¹. La solution consiste alors à avoir un processus qui surveille si le service qui est censé être assuré l'est effectivement.
Mais bien sûr, la bonne solution est de supprimer l'origine du plantage.
1 : démonstration : soit un test universel de plantage d'un processus, alors j'écris un démon qui fait son travail si et seulement si le test signale qu'il est planté.
l'indien
On Sat, 08 Jan 2005 01:33:04 +0000, Nicolas George wrote:
l'indien wrote in message :
- Si il plante, il peut encore etre listé dans les processes actifs, donc inutile, voire impossible de le relancer (par exemple si il bind un port) Non. Quand un process reçoit un signal qui le tue, il devient zombie. Il
est impossible qu'il reste actif. Il est possible que le programme trappe le signal mais dans ce cas ... il ne plante pas !
Ça dépend ce qu'on entend par planter. Un processus qui est parti dans une boucle infinie à attendre des données sur un fd fermé ou une connerie comme ça, on peut raisonnablement dire qu'il est planté. Mais rien ne permet génériquement de le déterminer¹. La solution consiste alors à avoir un processus qui surveille si le service qui est censé être assuré l'est effectivement.
Bon OK, c'est un problème de vocabulaire... Ce que tu décris, j'appelle ça un bug, mais pas un plantage... Pour ces cas là, il faut appliquer le principe du watchdog: le process à surveiller doit écrire dans un fichier (plutôt une socket unix ou un pipe...) régulièrement sous peine d'être relancé. Si c'est fait correctement, ce genre de bug sera dépisté.
Mais bien sûr, la bonne solution est de supprimer l'origine du plantage.
Bien sur. Mais il est peut être interressant d'avoir un process qui fait le monitoring des daemons et prévient l'administrateur système s'il a à intervenir. Il peut même faire un core-dump des process au moment ou il décide de les relancer pour faciliter le debug. A mon avis, ça pourrait mériter d'être une feature standard d'init...
On Sat, 08 Jan 2005 01:33:04 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2005.01.08.00.13.50.351752@magic.fr>:
- Si il plante, il peut encore etre listé dans les processes actifs, donc
inutile, voire impossible de le relancer (par exemple si il bind un port)
Non. Quand un process reçoit un signal qui le tue, il devient zombie. Il
est impossible qu'il reste actif. Il est possible que le programme trappe
le signal mais dans ce cas ... il ne plante pas !
Ça dépend ce qu'on entend par planter. Un processus qui est parti dans une
boucle infinie à attendre des données sur un fd fermé ou une connerie comme
ça, on peut raisonnablement dire qu'il est planté. Mais rien ne permet
génériquement de le déterminer¹. La solution consiste alors à avoir un
processus qui surveille si le service qui est censé être assuré l'est
effectivement.
Bon OK, c'est un problème de vocabulaire...
Ce que tu décris, j'appelle ça un bug, mais pas un plantage...
Pour ces cas là, il faut appliquer le principe du watchdog:
le process à surveiller doit écrire dans un fichier (plutôt une socket
unix ou un pipe...) régulièrement sous peine d'être relancé. Si c'est
fait correctement, ce genre de bug sera dépisté.
Mais bien sûr, la bonne solution est de supprimer l'origine du plantage.
Bien sur. Mais il est peut être interressant d'avoir un process qui fait
le monitoring des daemons et prévient l'administrateur système s'il a à
intervenir. Il peut même faire un core-dump des process au moment ou il
décide de les relancer pour faciliter le debug. A mon avis, ça pourrait
mériter d'être une feature standard d'init...
On Sat, 08 Jan 2005 01:33:04 +0000, Nicolas George wrote:
l'indien wrote in message :
- Si il plante, il peut encore etre listé dans les processes actifs, donc inutile, voire impossible de le relancer (par exemple si il bind un port) Non. Quand un process reçoit un signal qui le tue, il devient zombie. Il
est impossible qu'il reste actif. Il est possible que le programme trappe le signal mais dans ce cas ... il ne plante pas !
Ça dépend ce qu'on entend par planter. Un processus qui est parti dans une boucle infinie à attendre des données sur un fd fermé ou une connerie comme ça, on peut raisonnablement dire qu'il est planté. Mais rien ne permet génériquement de le déterminer¹. La solution consiste alors à avoir un processus qui surveille si le service qui est censé être assuré l'est effectivement.
Bon OK, c'est un problème de vocabulaire... Ce que tu décris, j'appelle ça un bug, mais pas un plantage... Pour ces cas là, il faut appliquer le principe du watchdog: le process à surveiller doit écrire dans un fichier (plutôt une socket unix ou un pipe...) régulièrement sous peine d'être relancé. Si c'est fait correctement, ce genre de bug sera dépisté.
Mais bien sûr, la bonne solution est de supprimer l'origine du plantage.
Bien sur. Mais il est peut être interressant d'avoir un process qui fait le monitoring des daemons et prévient l'administrateur système s'il a à intervenir. Il peut même faire un core-dump des process au moment ou il décide de les relancer pour faciliter le debug. A mon avis, ça pourrait mériter d'être une feature standard d'init...
Nicolas George
l'indien wrote in message :
Pour ces cas là, il faut appliquer le principe du watchdog: le process à surveiller doit écrire dans un fichier (plutôt une socket unix ou un pipe...) régulièrement sous peine d'être relancé.
Euh, non, dans ce sens-là, ça ne marche pas : le démon peut être tout à fait opérationnel au moment de dire périodiquement qu'il foncionne, et pourtant incapable d'assurer le service qu'il doit assurer. Typiquement, si la structure est ainsi :
boucle infinie { attendre si connexion gérer connexion si timeout écrire pour le watchdog }
gérer connexion { si quelque chose ne marche pas (*) retour faire le service }
Si le problème est là où j'ai mis une étoile, le démon écrira sans problème pour le watchdog, mais sera tout à fait inopérant.
La seule solution viable pour un watchdog, c'est de tester précisément sur le service qui doit être assuré : faire une requête web sur un serveur web, tenter d'envoyer un mail sur un serveur SMTP, etc. Évidemment, ça ne peut pas tester tous les cas.
l'indien wrote in message <pan.2005.01.08.13.10.25.206704@magic.fr>:
Pour ces cas là, il faut appliquer le principe du watchdog:
le process à surveiller doit écrire dans un fichier (plutôt une socket
unix ou un pipe...) régulièrement sous peine d'être relancé.
Euh, non, dans ce sens-là, ça ne marche pas : le démon peut être tout à fait
opérationnel au moment de dire périodiquement qu'il foncionne, et pourtant
incapable d'assurer le service qu'il doit assurer. Typiquement, si la
structure est ainsi :
boucle infinie {
attendre
si connexion
gérer connexion
si timeout
écrire pour le watchdog
}
gérer connexion {
si quelque chose ne marche pas (*)
retour
faire le service
}
Si le problème est là où j'ai mis une étoile, le démon écrira sans problème
pour le watchdog, mais sera tout à fait inopérant.
La seule solution viable pour un watchdog, c'est de tester précisément sur
le service qui doit être assuré : faire une requête web sur un serveur web,
tenter d'envoyer un mail sur un serveur SMTP, etc. Évidemment, ça ne peut
pas tester tous les cas.
Pour ces cas là, il faut appliquer le principe du watchdog: le process à surveiller doit écrire dans un fichier (plutôt une socket unix ou un pipe...) régulièrement sous peine d'être relancé.
Euh, non, dans ce sens-là, ça ne marche pas : le démon peut être tout à fait opérationnel au moment de dire périodiquement qu'il foncionne, et pourtant incapable d'assurer le service qu'il doit assurer. Typiquement, si la structure est ainsi :
boucle infinie { attendre si connexion gérer connexion si timeout écrire pour le watchdog }
gérer connexion { si quelque chose ne marche pas (*) retour faire le service }
Si le problème est là où j'ai mis une étoile, le démon écrira sans problème pour le watchdog, mais sera tout à fait inopérant.
La seule solution viable pour un watchdog, c'est de tester précisément sur le service qui doit être assuré : faire une requête web sur un serveur web, tenter d'envoyer un mail sur un serveur SMTP, etc. Évidemment, ça ne peut pas tester tous les cas.
Rakotomandimby (R12y) Mihamina
( Fri, 07 Jan 2005 23:36:23 +0000 ) Nicolas George :
- Si un programme quelconque plante, ben il ne peut pas envoyer un signal du genre "SIGPLANTE" puisqu'il est planté.
Si : il envoit un SIGCHLD (ou plutôt le noyau le fait) à son père.
Ah?! Et tous les process ont des peres (et des fils)? Je dis ca parceque si chaque process a un fils, ce meme fils aura un fils, etc etc... On en finira pas.
Ou bien c'est parceque c'est un deamon, c'est pour ca? -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
( Fri, 07 Jan 2005 23:36:23 +0000 ) Nicolas George :
- Si un programme quelconque plante, ben il ne peut pas envoyer un
signal du genre "SIGPLANTE" puisqu'il est planté.
Si : il envoit un SIGCHLD (ou plutôt le noyau le fait) à son père.
Ah?!
Et tous les process ont des peres (et des fils)? Je dis ca parceque si
chaque process a un fils, ce meme fils aura un fils, etc etc... On en
finira pas.
Ou bien c'est parceque c'est un deamon, c'est pour ca?
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
( Fri, 07 Jan 2005 23:36:23 +0000 ) Nicolas George :
- Si un programme quelconque plante, ben il ne peut pas envoyer un signal du genre "SIGPLANTE" puisqu'il est planté.
Si : il envoit un SIGCHLD (ou plutôt le noyau le fait) à son père.
Ah?! Et tous les process ont des peres (et des fils)? Je dis ca parceque si chaque process a un fils, ce meme fils aura un fils, etc etc... On en finira pas.
Ou bien c'est parceque c'est un deamon, c'est pour ca? -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
Nicolas George
R12y wrote in message :
Et tous les process ont des peres (et des fils)?
Tout processus sauf init a un père. Cf. l'option f de ps (qui bizarrement ne montre pas la parenté avec init).
R12y wrote in message <pan.2005.01.09.12.17.22.282229@mail.rktmb.org>:
Et tous les process ont des peres (et des fils)?
Tout processus sauf init a un père. Cf. l'option f de ps (qui bizarrement ne
montre pas la parenté avec init).
Tout processus sauf init a un père. Cf. l'option f de ps (qui bizarrement ne montre pas la parenté avec init).
l'indien
On Sat, 08 Jan 2005 14:06:40 +0000, Nicolas George wrote:
l'indien wrote in message :
Pour ces cas là, il faut appliquer le principe du watchdog: le process à surveiller doit écrire dans un fichier (plutôt une socket unix ou un pipe...) régulièrement sous peine d'être relancé.
Euh, non, dans ce sens-là, ça ne marche pas : le démon peut être tout à fait opérationnel au moment de dire périodiquement qu'il foncionne, et pourtant incapable d'assurer le service qu'il doit assurer. Typiquement, si la structure est ainsi :
boucle infinie { attendre si connexion gérer connexion si timeout écrire pour le watchdog }
gérer connexion { si quelque chose ne marche pas (*) retour faire le service }
Si le problème est là où j'ai mis une étoile, le démon écrira sans problème pour le watchdog, mais sera tout à fait inopérant.
Oui, mais là, franchement, ça tient de la bêtise... Si un programme voit explicitement qu'il ne peut pas assurer son service, il n'y a pas lieu d'utiliser un autre programme pour le monitorer ! Si le programme est en erreur grave, qu'il ne peut pas corriger, il se termine ou se réinitialise. Tout autre comportement est absurde.
La seule solution viable pour un watchdog, c'est de tester précisément sur le service qui doit être assuré : faire une requête web sur un serveur web, tenter d'envoyer un mail sur un serveur SMTP, etc. Évidemment, ça ne peut pas tester tous les cas.
C'est loin d'être toujours possible et quand c'est possible, ce n'est pas toujours sain... En tout cas, ce n'est plus un watchdog.
On Sat, 08 Jan 2005 14:06:40 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2005.01.08.13.10.25.206704@magic.fr>:
Pour ces cas là, il faut appliquer le principe du watchdog:
le process à surveiller doit écrire dans un fichier (plutôt une socket
unix ou un pipe...) régulièrement sous peine d'être relancé.
Euh, non, dans ce sens-là, ça ne marche pas : le démon peut être tout à fait
opérationnel au moment de dire périodiquement qu'il foncionne, et pourtant
incapable d'assurer le service qu'il doit assurer. Typiquement, si la
structure est ainsi :
boucle infinie {
attendre
si connexion
gérer connexion
si timeout
écrire pour le watchdog
}
gérer connexion {
si quelque chose ne marche pas (*)
retour
faire le service
}
Si le problème est là où j'ai mis une étoile, le démon écrira sans problème
pour le watchdog, mais sera tout à fait inopérant.
Oui, mais là, franchement, ça tient de la bêtise...
Si un programme voit explicitement qu'il ne peut pas assurer son service,
il n'y a pas lieu d'utiliser un autre programme pour le monitorer !
Si le programme est en erreur grave, qu'il ne peut pas corriger, il se
termine ou se réinitialise. Tout autre comportement est absurde.
La seule solution viable pour un watchdog, c'est de tester précisément sur
le service qui doit être assuré : faire une requête web sur un serveur web,
tenter d'envoyer un mail sur un serveur SMTP, etc. Évidemment, ça ne peut
pas tester tous les cas.
C'est loin d'être toujours possible et quand c'est possible, ce n'est pas
toujours sain... En tout cas, ce n'est plus un watchdog.
On Sat, 08 Jan 2005 14:06:40 +0000, Nicolas George wrote:
l'indien wrote in message :
Pour ces cas là, il faut appliquer le principe du watchdog: le process à surveiller doit écrire dans un fichier (plutôt une socket unix ou un pipe...) régulièrement sous peine d'être relancé.
Euh, non, dans ce sens-là, ça ne marche pas : le démon peut être tout à fait opérationnel au moment de dire périodiquement qu'il foncionne, et pourtant incapable d'assurer le service qu'il doit assurer. Typiquement, si la structure est ainsi :
boucle infinie { attendre si connexion gérer connexion si timeout écrire pour le watchdog }
gérer connexion { si quelque chose ne marche pas (*) retour faire le service }
Si le problème est là où j'ai mis une étoile, le démon écrira sans problème pour le watchdog, mais sera tout à fait inopérant.
Oui, mais là, franchement, ça tient de la bêtise... Si un programme voit explicitement qu'il ne peut pas assurer son service, il n'y a pas lieu d'utiliser un autre programme pour le monitorer ! Si le programme est en erreur grave, qu'il ne peut pas corriger, il se termine ou se réinitialise. Tout autre comportement est absurde.
La seule solution viable pour un watchdog, c'est de tester précisément sur le service qui doit être assuré : faire une requête web sur un serveur web, tenter d'envoyer un mail sur un serveur SMTP, etc. Évidemment, ça ne peut pas tester tous les cas.
C'est loin d'être toujours possible et quand c'est possible, ce n'est pas toujours sain... En tout cas, ce n'est plus un watchdog.
