Bonjour.
Je fais dans le process sécurisé, et donc j'ai déjà développé un
watchdog logiciel qui surveille un autre process afin de le tuer et
relancer s'il se bloque (je maîtrise mes algos mais pas ce qui se
passe dans les librairies système).
Ca repose évidemment sur un système de heart-beat régulier, mais ce
principe suppose que le process soit conçu en ce sens.
Comment feriez-vous pour surveiller de même une application lambda
pour laquelle ça n'a pas été prévu ?
Il est déjà possible de surveiller son handle de process, ce qui
permet de détecter sa mort éventuelle. Mais si l'application se met
dans un état second, comment le détecter (autrement qu'en essayant de
la fermer et en s'apercevant qu'elle ne répond pas, moi je veux
qu'elle reste en fonctionnement) ?
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
c'est pas évident. Vous voyez plus simple ?
Merci de toute suggestion.
Cordialement,
PZB
Bonjour.
Je fais dans le process sécurisé, et donc j'ai déjà développé un
watchdog logiciel qui surveille un autre process afin de le tuer et
relancer s'il se bloque (je maîtrise mes algos mais pas ce qui se
passe dans les librairies système).
Ca repose évidemment sur un système de heart-beat régulier, mais ce
principe suppose que le process soit conçu en ce sens.
Comment feriez-vous pour surveiller de même une application lambda
pour laquelle ça n'a pas été prévu ?
Il est déjà possible de surveiller son handle de process, ce qui
permet de détecter sa mort éventuelle. Mais si l'application se met
dans un état second, comment le détecter (autrement qu'en essayant de
la fermer et en s'apercevant qu'elle ne répond pas, moi je veux
qu'elle reste en fonctionnement) ?
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
c'est pas évident. Vous voyez plus simple ?
Merci de toute suggestion.
Cordialement,
PZB
Bonjour.
Je fais dans le process sécurisé, et donc j'ai déjà développé un
watchdog logiciel qui surveille un autre process afin de le tuer et
relancer s'il se bloque (je maîtrise mes algos mais pas ce qui se
passe dans les librairies système).
Ca repose évidemment sur un système de heart-beat régulier, mais ce
principe suppose que le process soit conçu en ce sens.
Comment feriez-vous pour surveiller de même une application lambda
pour laquelle ça n'a pas été prévu ?
Il est déjà possible de surveiller son handle de process, ce qui
permet de détecter sa mort éventuelle. Mais si l'application se met
dans un état second, comment le détecter (autrement qu'en essayant de
la fermer et en s'apercevant qu'elle ne répond pas, moi je veux
qu'elle reste en fonctionnement) ?
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
c'est pas évident. Vous voyez plus simple ?
Merci de toute suggestion.
Cordialement,
PZB
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais c'est
pas évident. Vous voyez plus simple ?
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais c'est
pas évident. Vous voyez plus simple ?
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais c'est
pas évident. Vous voyez plus simple ?
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
c'est pas évident. Vous voyez plus simple ?
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
c'est pas évident. Vous voyez plus simple ?
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
c'est pas évident. Vous voyez plus simple ?
Bonjour,
Patrick "Zener" BRUNET a écrit :
> J'en suis à envisager des choses du style : envoyer périodiquement des
> messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
^^^^^^^^^^ ^^^ ^^^ ^^^^
> c'est pas évident. Vous voyez plus simple ?
WM_NULL serait mieux, avec un SendMessageTimeout.
(de toutre façon voir le message de CAstor).
Bonjour,
Patrick "Zener" BRUNET a écrit :
> J'en suis à envisager des choses du style : envoyer périodiquement des
> messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
^^^^^^^^^^ ^^^ ^^^ ^^^^
> c'est pas évident. Vous voyez plus simple ?
WM_NULL serait mieux, avec un SendMessageTimeout.
(de toutre façon voir le message de CAstor).
Bonjour,
Patrick "Zener" BRUNET a écrit :
> J'en suis à envisager des choses du style : envoyer périodiquement des
> messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
^^^^^^^^^^ ^^^ ^^^ ^^^^
> c'est pas évident. Vous voyez plus simple ?
WM_NULL serait mieux, avec un SendMessageTimeout.
(de toutre façon voir le message de CAstor).
Bonjour.
Je fais dans le process sécurisé, et donc j'ai déjà développé un
watchdog logiciel qui surveille un autre process afin de le tuer et
relancer s'il se bloque (je maîtrise mes algos mais pas ce qui se
passe dans les librairies système).
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
c'est pas évident. Vous voyez plus simple ?
Bonjour.
Je fais dans le process sécurisé, et donc j'ai déjà développé un
watchdog logiciel qui surveille un autre process afin de le tuer et
relancer s'il se bloque (je maîtrise mes algos mais pas ce qui se
passe dans les librairies système).
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
c'est pas évident. Vous voyez plus simple ?
Bonjour.
Je fais dans le process sécurisé, et donc j'ai déjà développé un
watchdog logiciel qui surveille un autre process afin de le tuer et
relancer s'il se bloque (je maîtrise mes algos mais pas ce qui se
passe dans les librairies système).
J'en suis à envisager des choses du style : envoyer périodiquement des
messages de déplacement à sa fenêtre, et vérifier qu'elle obéit, mais
c'est pas évident. Vous voyez plus simple ?
"Thierry" a écrit dans le message de
news:
> Bonjour,
>
> Patrick "Zener" BRUNET a écrit :
>
> > J'en suis à envisager des choses du style : envoyer périodiquement
> > des messages de déplacement à sa fenêtre, et vérifier qu'elle
> > obéit, mais ^^^^^^^^^^ ^^^ ^^^ ^^^^ c'est pas évident. Vous
> > voyez plus simple ?
>
> WM_NULL serait mieux, avec un SendMessageTimeout.
> (de toutre façon voir le message de CAstor).
>
Certes mais une application peut ne pas répondre au bout du Timeout
est ne pas être bloquée pour autant... Si elle fait un (long) calcul
et qu'elle ne possède qu'un seul thread... D'accord elle est mal
écrite, mais ça c'est vu ;-)
"Thierry" <yarglah@com.invalid> a écrit dans le message de
news:XnF94139124D209Dpouletetcetc@213.228.0.138...
> Bonjour,
>
> Patrick "Zener" BRUNET a écrit :
>
> > J'en suis à envisager des choses du style : envoyer périodiquement
> > des messages de déplacement à sa fenêtre, et vérifier qu'elle
> > obéit, mais ^^^^^^^^^^ ^^^ ^^^ ^^^^ c'est pas évident. Vous
> > voyez plus simple ?
>
> WM_NULL serait mieux, avec un SendMessageTimeout.
> (de toutre façon voir le message de CAstor).
>
Certes mais une application peut ne pas répondre au bout du Timeout
est ne pas être bloquée pour autant... Si elle fait un (long) calcul
et qu'elle ne possède qu'un seul thread... D'accord elle est mal
écrite, mais ça c'est vu ;-)
"Thierry" a écrit dans le message de
news:
> Bonjour,
>
> Patrick "Zener" BRUNET a écrit :
>
> > J'en suis à envisager des choses du style : envoyer périodiquement
> > des messages de déplacement à sa fenêtre, et vérifier qu'elle
> > obéit, mais ^^^^^^^^^^ ^^^ ^^^ ^^^^ c'est pas évident. Vous
> > voyez plus simple ?
>
> WM_NULL serait mieux, avec un SendMessageTimeout.
> (de toutre façon voir le message de CAstor).
>
Certes mais une application peut ne pas répondre au bout du Timeout
est ne pas être bloquée pour autant... Si elle fait un (long) calcul
et qu'elle ne possède qu'un seul thread... D'accord elle est mal
écrite, mais ça c'est vu ;-)
"Patrick "Zener" BRUNET" <http://zener131.free.fr/ContactMe> a écrit
dans le message news: 3f8a60c9$0$27046$
Bonjour.
Merci beaucoup de ces suggestions très intéressantes. Je pense que je
vais doter mon Watchdog d'une petite intelligence reposant sur ces
différents indices.
Pour ceux qui seraient intéressés par la suite:
Si le Watchdog conclut que le proicess qu'il surveille est planté,
alors il le tue et tente de le relancer.
Le process normalement utilisé est programmé pour se remettre au
travail sur sa tâche en cours, sinon ça n'a bien sûr aucun intérêt.
Quelquefois, le process est incapable de se remettre au travail
(ressource plantée ou autre). Dans ce cas, le Watchdog après 2
tentatives, décide de rebooter le système, ce qui suppose que lui-même
et le process sont inscrits dans la liste de démarrage, et qu'un
auto-logon est prévu.
Donc le Watchdog commence par envoyer une commande de reboot soft
(fermez-vous svp) afin de laisser une chance aux diverses applis de se
terminer proprement, et après un délai si ça échoue, il commande un
reboot forcé.
Mais ça ne suffit pas, quelquefois windows lui-même est dans un tel
état qu'il est incapable de rebooter (et en général à ce stade le
Watchdog est planté aussi).
Dans ce cas, la seule solution est un reboot hard, ce qui signifie que
je vais devoir coupler mon Watchdog logiciel avec un petit boîtier
électronique contenant un timer redéclenchable, auquel il envoie un
heart beat, et capable d'actionner le contact reset du PC. La
solution élégante est de faire une carte PCI (la revue Elektor a
publié tout ce qu'il faut pour l'interfaçage), la solution économique
est de monter ça sur un port série.
Qu'est-ce qu'il ne faut pas faire pour pouvoir compter sur un process
!
"Patrick "Zener" BRUNET" <http://zener131.free.fr/ContactMe> a écrit
dans le message news: 3f8a60c9$0$27046$626a54ce@news.free.fr...
Bonjour.
Merci beaucoup de ces suggestions très intéressantes. Je pense que je
vais doter mon Watchdog d'une petite intelligence reposant sur ces
différents indices.
Pour ceux qui seraient intéressés par la suite:
Si le Watchdog conclut que le proicess qu'il surveille est planté,
alors il le tue et tente de le relancer.
Le process normalement utilisé est programmé pour se remettre au
travail sur sa tâche en cours, sinon ça n'a bien sûr aucun intérêt.
Quelquefois, le process est incapable de se remettre au travail
(ressource plantée ou autre). Dans ce cas, le Watchdog après 2
tentatives, décide de rebooter le système, ce qui suppose que lui-même
et le process sont inscrits dans la liste de démarrage, et qu'un
auto-logon est prévu.
Donc le Watchdog commence par envoyer une commande de reboot soft
(fermez-vous svp) afin de laisser une chance aux diverses applis de se
terminer proprement, et après un délai si ça échoue, il commande un
reboot forcé.
Mais ça ne suffit pas, quelquefois windows lui-même est dans un tel
état qu'il est incapable de rebooter (et en général à ce stade le
Watchdog est planté aussi).
Dans ce cas, la seule solution est un reboot hard, ce qui signifie que
je vais devoir coupler mon Watchdog logiciel avec un petit boîtier
électronique contenant un timer redéclenchable, auquel il envoie un
heart beat, et capable d'actionner le contact reset du PC. La
solution élégante est de faire une carte PCI (la revue Elektor a
publié tout ce qu'il faut pour l'interfaçage), la solution économique
est de monter ça sur un port série.
Qu'est-ce qu'il ne faut pas faire pour pouvoir compter sur un process
!
"Patrick "Zener" BRUNET" <http://zener131.free.fr/ContactMe> a écrit
dans le message news: 3f8a60c9$0$27046$
Bonjour.
Merci beaucoup de ces suggestions très intéressantes. Je pense que je
vais doter mon Watchdog d'une petite intelligence reposant sur ces
différents indices.
Pour ceux qui seraient intéressés par la suite:
Si le Watchdog conclut que le proicess qu'il surveille est planté,
alors il le tue et tente de le relancer.
Le process normalement utilisé est programmé pour se remettre au
travail sur sa tâche en cours, sinon ça n'a bien sûr aucun intérêt.
Quelquefois, le process est incapable de se remettre au travail
(ressource plantée ou autre). Dans ce cas, le Watchdog après 2
tentatives, décide de rebooter le système, ce qui suppose que lui-même
et le process sont inscrits dans la liste de démarrage, et qu'un
auto-logon est prévu.
Donc le Watchdog commence par envoyer une commande de reboot soft
(fermez-vous svp) afin de laisser une chance aux diverses applis de se
terminer proprement, et après un délai si ça échoue, il commande un
reboot forcé.
Mais ça ne suffit pas, quelquefois windows lui-même est dans un tel
état qu'il est incapable de rebooter (et en général à ce stade le
Watchdog est planté aussi).
Dans ce cas, la seule solution est un reboot hard, ce qui signifie que
je vais devoir coupler mon Watchdog logiciel avec un petit boîtier
électronique contenant un timer redéclenchable, auquel il envoie un
heart beat, et capable d'actionner le contact reset du PC. La
solution élégante est de faire une carte PCI (la revue Elektor a
publié tout ce qu'il faut pour l'interfaçage), la solution économique
est de monter ça sur un port série.
Qu'est-ce qu'il ne faut pas faire pour pouvoir compter sur un process
!
J'ose te demander quelle application est à la fois si laxiste qu'elle
peut supporte une panne momentané, si mal programmée qu'un plantage peut
toujours arriver et si nécessaire qu'un reboot peut être imaginé?
Perso, j'ai toujours préféré regardé pq ça plante et arranger cela (que
ce soit dans mon code ou pas) plutôt que d'appliquer le "ça plante, je
reboot", cher à certains mauvais admins...
Enfin bref, j'imagine que tu as réfléchi à tous cela et que ton contexte
s'y prête, mais ça m'intéresse, si tu pouvais m'en dire plus!
J'ose te demander quelle application est à la fois si laxiste qu'elle
peut supporte une panne momentané, si mal programmée qu'un plantage peut
toujours arriver et si nécessaire qu'un reboot peut être imaginé?
Perso, j'ai toujours préféré regardé pq ça plante et arranger cela (que
ce soit dans mon code ou pas) plutôt que d'appliquer le "ça plante, je
reboot", cher à certains mauvais admins...
Enfin bref, j'imagine que tu as réfléchi à tous cela et que ton contexte
s'y prête, mais ça m'intéresse, si tu pouvais m'en dire plus!
J'ose te demander quelle application est à la fois si laxiste qu'elle
peut supporte une panne momentané, si mal programmée qu'un plantage peut
toujours arriver et si nécessaire qu'un reboot peut être imaginé?
Perso, j'ai toujours préféré regardé pq ça plante et arranger cela (que
ce soit dans mon code ou pas) plutôt que d'appliquer le "ça plante, je
reboot", cher à certains mauvais admins...
Enfin bref, j'imagine que tu as réfléchi à tous cela et que ton contexte
s'y prête, mais ça m'intéresse, si tu pouvais m'en dire plus!
> Pour le projet initial, il s'agissait d'un projet confidentiel, mais
globalement il s'agissait de gérer via un réseau et Internet des
transactions où des sommes d'argent importantes sont en jeu, et ceci
de manière autonome (personne devant le PC).
Le process peut supporter d'être interrompu quelques minutes, mais il
est hors de question de découvrir le soir à 19h00 qu'il est planté
depuis 10h00 et que le client est ruiné depuis 11h00.
Pourquoi ça planterait alors ? Je te rassure, je fais du 0 error, 0
warning, je traque toutes les allocations et libérations de
ressources, et tous les cas d'erreurs plausibles. Mais malheureusement
on ne maîtrise pas tout dans un logiciel, et notamment tout ce qui se
passe au niveau des librairies, drivers et autres.
> Pour le projet initial, il s'agissait d'un projet confidentiel, mais
globalement il s'agissait de gérer via un réseau et Internet des
transactions où des sommes d'argent importantes sont en jeu, et ceci
de manière autonome (personne devant le PC).
Le process peut supporter d'être interrompu quelques minutes, mais il
est hors de question de découvrir le soir à 19h00 qu'il est planté
depuis 10h00 et que le client est ruiné depuis 11h00.
Pourquoi ça planterait alors ? Je te rassure, je fais du 0 error, 0
warning, je traque toutes les allocations et libérations de
ressources, et tous les cas d'erreurs plausibles. Mais malheureusement
on ne maîtrise pas tout dans un logiciel, et notamment tout ce qui se
passe au niveau des librairies, drivers et autres.
> Pour le projet initial, il s'agissait d'un projet confidentiel, mais
globalement il s'agissait de gérer via un réseau et Internet des
transactions où des sommes d'argent importantes sont en jeu, et ceci
de manière autonome (personne devant le PC).
Le process peut supporter d'être interrompu quelques minutes, mais il
est hors de question de découvrir le soir à 19h00 qu'il est planté
depuis 10h00 et que le client est ruiné depuis 11h00.
Pourquoi ça planterait alors ? Je te rassure, je fais du 0 error, 0
warning, je traque toutes les allocations et libérations de
ressources, et tous les cas d'erreurs plausibles. Mais malheureusement
on ne maîtrise pas tout dans un logiciel, et notamment tout ce qui se
passe au niveau des librairies, drivers et autres.
