Comment propager un signal Kill d'un process vers un autre sous windows ?

Bonjour tout le monde,

J'ai 3 Processus P1, P2 et P3:
* P1: service windows prêt que j'utilise pour lancer P2(c'est pas le mien ce service, je peux m'en servir mais je peux pas modifier son code. Pour lancer P2, je fais une petite config dans la clé de registre).
* P2, P3 : deux processus dont le code est le mien, donc je peux y agir et modifier.
Le but c'est d'assurer :
a)un lancement en cascade(P1 lance P2 , P2 lance P3 , ça je l'ai fait déja : quand P2 se lance , il lance P3 avec CreateProcess() )
b)un arrêt en cascade(arrêt de P1 => arrêt de P2 => arrêt de P3 )( ça je vois pas comment le faire )

Quand P1 s'arrête il tue P2 par un kill ( je pense .., je suis pas sûr ) donc P3 ne reçoit rien de la part de P2 et par suite reste en exécution.

Alors, y'a une solution qui consiste à faire une vérification périodique dans P3 de l'état d'exécution de P2 et faire un exit s'il est arrêté ..
Mais comme vous savez le problème de consommation de vérification périodique et aussi le problème de choix de la période ...

Alors est ce qu'il n'y a pas un autre moyen plus propre pour faire ça ?

Merci pour vos réponses :)

Les signaux POSIX (kill) sous Windows, même pas en rêve.

P2 et P3 sont-ils aux aussi des services Windows ?

Sinon, le plus simple est de faire des attentes sur handler de processus dans des threads dédiés.

En clair, cela dépend du bricolage de P1, qui devrait être documenté d'ailleurs

L'arrêt d'un service sous Windows, tout comme les dépendances entre services, sont des opérations "propres", et non pas des kill bourrins...

Voir MSDN pour l'API de gestion des services.

Citation:

---

Envoyé par bacelar

Les signaux POSIX (kill) sous Windows, même pas en rêve.

---

Y'a pas un équivalent en Win32 ?!

Citation:

---

P2 et P3 sont-ils aux aussi des services Windows ?

---

Non, se sont des processus "ordinaires" .

Citation:

---

Sinon, le plus simple est de faire des attentes sur handler de processus dans des threads dédiés.

---

Un exit(-1) (Après une attente sur le handler )dans un thread crée par P3 dédié à contrôler l'état de P2 engendre l'arrêt de P3 ? Je pense oui, mais je suis pas sûr ( test en cours ..)

Citation:

---

En clair, cela dépend du bricolage de P1, qui devrait être documenté d'ailleurs

---

La doc n'est pas précise en ce point malheureusement.

Citation:

---

Y'a pas un équivalent en Win32 ?!

---

La dernière fois, c'était en Win16 et c'était une usine à gaz sur le point d'exploser. C'est peut-être faisable dans le sous-système POSIX mais pas dans le sous-système Win32.

Citation:

---

Un exit(-1) (Après une attente sur le handler )dans un thread crée par P3 dédié à contrôler l'état de P2 engendre l'arrêt de P3 ? Je pense oui, mais je suis pas sûr ( test en cours ..)

---

Heu, là c'est vraiment gore comme autodestruction. Le plus polie est soit envoyer de message pour une application graphique soit le déclanchement d'un objet Kernel "Event".

Citation:

---

La doc n'est pas précise en ce point malheureusement.

---

Envoies le lien, on décortiquera.

Mais, dans l'absolu, lancer des programmes non Service-Windows Aware à partir d'un service Windows, c'est s'exposé à de grosse déconvenue (sécurité, debugging etc...)

Citation:

---

Envoyé par masterx_goldman

Un exit(-1) (Après une attente sur le handler )dans un thread crée par P3 dédié à contrôler l'état de P2 engendre l'arrêt de P3 ? Je pense oui, mais je suis pas sûr ( test en cours ..)

---

Pour info, j'ai essayé le exit(-1) dans le code du thread => on sort de tout le programme ;)
ça m'arrange dans ce cas :ccool:

maintenant, je pense que je dois utiliser un WaitForSingleObject mais je sais pas comment m'en servir dans ce cas :oops:
Voilà comment je vois le code pour le moment, mais je sais pas si le Handle obtenu sur le processus P2 va être mis à l'état SIGNALED quand celui ci s'arrête brusquement ou bien il va être dans un autre état..
Bon, voici un exemple de code, je sais pas s'il va être suffisant ou pas , merci de me le corriger :)

Code:

---

1 2 3 4 5 6 7 8 9

UINT __cdecl ControlerThread( LPVOID pParameters ) { DWORD processID=GetPidByName("P2.exe");// j'obtient le PID du process P2 par une fonction prédéfinie GetPidByName HANDLE hP2=OpenProcess( PROCESS_QUERY_INFORMATION ,FALSE, processID ); WaitForSingleObject(hP2,INFINITE); exit(-1); return 0; }

---

Citation:

---

Envoyé par masterx_goldman

Y'a pas un équivalent en Win32 ?!

---

Cela oscille entre la messagerie Windows classique et le contrôle par l'API. En tout cas, les signaux n'ont aucun sens sous Windows, il y a d'autres méthodes pour contrôler les processus.

Pour le reste, tu peux demander la terminaison de tes processus "proprement" au niveau du gestionnaire d'arrêt de ton service (essaie toujours de poster un WM_QUIT ou autre message, sait-on jamais...), ce sera toujours plus propre que de flinguer les processus façon sauvage.

Citation:

---

Envoyé par bacelar

La dernière fois, c'était en Win16 et c'était une usine à gaz sur le point d'exploser. C'est peut-être faisable dans le sous-système POSIX mais pas dans le sous-système Win32.

---

Dans ce cas, comment on paut arrêter un processus windows ?

Citation:

---

Heu, là c'est vraiment gore comme autodestruction. Le plus polie est soit envoyer de message pour une application graphique soit le déclanchement d'un objet Kernel "Event".

---

J'ai aucun truc graphique, le Event me parait plus convenable.
Où dois je déclarer l'Event ? et comment le thread lancé par P3 peut s'en servir ?

Citation:

---

Envoies le lien, on décortiquera.

---

C'est pas docuementé sur le net, c'est développé par une entreprise et la doc fournie est trop superficielle ...

Citation:

---

Mais, dans l'absolu, lancer des programmes non Service-Windows Aware à partir d'un service Windows, c'est s'exposé à de grosse déconvenue (sécurité, debugging etc...)

---

J'ai pas trop compris ça :oops:

Aussi bien sous POSIX que sous Windows, un vrai kill est indétectable, un processus est donc incapable de le propager lui-même à ses fils.

Sous un Windows récent, tu peux faire un "job object" contenant un processus et ses descendants, et killer le job en un coup. C'est sale (aussi sale que killer un processus, en fait), mais ça a le mérite de marcher.

Mais si tu veux faire les choses bien, tu dois envoyer au processus P2 un ordre de se suicider (par un moyen restant à définir), qui le relaiera à P3 (probablement par le même moyen) avant de s'exécuter.

Citation:

---

Envoyé par masterx_goldman

Dans ce cas, comment on paut arrêter un processus windows ?

---

Tu le lui demandes gentiment, via un message Windows (WM_CLOSE, WM_QUIT, etc.) s'il possède une boucle de message, ou tu utilises l'API dédiée pour un service.

Si ton programme ne possède ni l'un, ni l'autre, alors il n'est pas censé être "arrêtable" depuis l'extérieur... Ce qui peut avoir deux causes :

• Mauvaise connaissance de Windows et non-respect des règles basiques d'implémentation, donc mauvais programme.
• Programme court et/ou critique ne devant JAMAIS être arrêté par une application extérieure, donc pas touche.

Sinon, bien sûr, tu as TerminateProcess pour le kill pur et dur : c'est très très crade, totalement impossible à intercepter, et tu risques pas mal de soucis de stabilité / fuites mémoire, mais bon...

Citation:

---

Envoyé par masterx_goldman

J'ai aucun truc graphique, le Event me parait plus convenable.
Où dois je déclarer l'Event ? et comment le thread lancé par P3 peut s'en servir ?

---

Tu crée l'event (nommé, donc global sur le système) dans le processus "maître", tu le signales depuis ce même processus, et côté P3 ton thread se contente d'attendre cet event. Une fois qu'il est signalé, c'est à toi de propager l'information depuis le thread afin d'arrêter proprement ton processus (nettoyage des allocations + arrêt propre du thread principal).

Citation:

---

Envoyé par masterx_goldman

J'ai pas trop compris ça :oops:

---

Un service n'est PAS un processus ordinaire, c'est un service. Un daemon sous *nix, si tu préfères. Il ne se contrôle pas comme un processus classique, n'a pas les mêmes droits ni les mêmes privilèges.
Lancer un processus "normal" depuis un service, surtout si le processus ne s'attends PAS à être lancé autrement que par l'utilisateur, c'est s'exposer à de gros risques (surtout si le service lance tout ça avec des droits d'administrateur...).

Avec le Exit(-1) dans un thread auxiliaire, vous allez au devant de graves problèmes. L'Exit(-1) va stopper net tous les threads de votre programme, y compris un éventuel thread en train d'écrire dans un fichier de configuration qui sera mal formaté et vous fera planter le programme au prochain redémarrage.
Enfin bref, ne jamais arrêter un programme sauvagement mais toujours en ordre. Votre thread auxiliaire prévient le thread principal de votre application que c'est le moment de plier bagage. Pour cela, le plus simple est de "Setter" un Event partagé entre le thread principal et le thread auxiliaire. Après avoir "Setter" cet Event, le thread auxiliaire s'arrête en sortant de la fonction par un simple "return" Le thread principal vérifie régulièrement l'état de l'Event et sort proprement en arrêtant d'éventuels autres threads auxiliaires (par une demande, pas à la sauvage, cette demande, cela peut être une paire d'Event, un pour demander l'arrêt du thread auxiliaire, l'autre pour acquitter le fait que le thread auxiliaire c'est terminé de manière ordonné (vous pouvez avantageusement remplacé le deuxième Event par l'handler sur le thread auxiliaire si vous avez pris la peine de le stocker quelque part) ).

Citation:

---

non Service-Windows Aware

---

Le fait d'être lancé par un service Windows veux dire qu'il sera vraisemblablement lancé dans le contexte de sécurité (WorkStation) des services qui n'ont pas le droit "d'écrire" sur l'écran de la personne connectée, entre autre.
Donc, le plus simple c'est de faire des services et pas des programmes "normaux".

Citation:

---

C'est pas docuementé sur le net, c'est développé par une entreprise et la doc fournie est trop superficielle ...

---

Cette documentation fourni bien le moyen par lequel P1 demande à P2 de se suicidé. Si P1 tue P2, laissez tomber cette cochonnerie et fait des services avec dépendances qui seront directement et correctement gérées par l'OS.

Citation:

---

Envoyé par bacelar

Avec le Exit(-1) dans un thread auxiliaire, vous allez au devant de graves problèmes. L'Exit(-1) va stopper net tous les threads de votre programme, y compris un éventuel thread en train d'écrire dans un fichier de configuration qui sera mal formaté et vous fera planter le programme au prochain redémarrage.

---

Oui je me rends compte maintenant du danger posé dans ce cas :aie:

Citation:

---

Votre thread auxiliaire prévient le thread principal de votre application que c'est le moment de plier bagage. Pour cela, le plus simple est de "Setter" un Event partagé entre le thread principal et le thread auxiliaire. Après avoir "Setter" cet Event, le thread auxiliaire s'arrête en sortant de la fonction par un simple "return"

---

Oui ça je l'ai déja, j'ai un évennement de terminaison hTerminateEvent déclaré dans le processus principal et les autres threads sont dans une boucle inifinie d'attente en état waitForMultipleObjects() et font un return dans le cas où le event hTerminate est signalé.

Code:

---

WaitForMultipleObjects(3, Handles, FALSE, INFINITE);// Handles est un tableau de Handle ..

---

Citation:

---

Le thread principal vérifie régulièrement l'état de l'Event et sort proprement en arrêtant d'éventuels autres threads auxiliaires (par une demande, pas à la sauvage, cette demande, cela peut être une paire d'Event, un pour demander l'arrêt du thread auxiliaire, l'autre pour acquitter le fait que le thread auxiliaire c'est terminé de manière ordonné (vous pouvez avantageusement remplacé le deuxième Event par l'handler sur le thread auxiliaire si vous avez pris la peine de le stocker quelque part) ).

---

Ok, bonne idée, je vais voir comment faire ça .. :ccool:

Citation:

---

Donc, le plus simple c'est de faire des services et pas des programmes "normaux".

---

Oui, tu as raison sauf que j'ai pas le droit à faire des services windows pour respecter les règles de fonctionnement des modules dans le produit que je suis entrain d'améliorer >_<

Quel architecte logiciel est assez stupide pour imposer des programmes "normaux" lancés par un service Windows ?

Maintenant, une question très importante:
Je reformule les données:
J'ai :
*P1(service windows)
*P2 et P3 : 2 processus ordinaires
* th_i :thread lancé par P3
* thAux: thread auxiliaire qui contrôle l'état de P2 ( lancé ou arrêté )

Comment faire pour faire attendre thAux sur un WaitForSingleObject() pour qu'il puisse retourner quand le processus P2 se termine ?

Comme tentative de début j'ai essayé d'obtenir un HANDLE sur P2 par OpenProcess() puis un WaitForSingleObject() mais le thread n'attend pas sur ce Wait .. ( c'est débil comme essai :aie: mais c'est dans ce sens que je veux faire les choses : thAux Attend la sortie de P2 et puis signale ça à son père P3 )

Merci pour tout type d'aide :)

Ça devrait pourtant marcher: Si tu as le droit SYNCHRONIZE sur le processus, tu dois pouvoir attendre qu'il se termine avec WaitForSingleObject()...

Citation:

---

Envoyé par Médinoc

Ça devrait pourtant marcher: Si tu as le droit SYNCHRONIZE sur le processus, tu dois pouvoir attendre qu'il se termine avec WaitForSingleObject()...

---

ça veut dire quoi ce droit et comment je peux vérifier si je l'ai ou pas ?

Rq: Je suis sous compte Administrateur

Généralement, tu l'as.
Par contre, il faut penser à le demander lors de l'appel à OpenProcess() ou équivalent...

Citation:

---

Envoyé par Médinoc

Ça devrait pourtant marcher: Si tu as le droit SYNCHRONIZE sur le processus, tu dois pouvoir attendre qu'il se termine avec WaitForSingleObject()...

---

héhé :yaisse2: ça marche avec SYNCHRONIZE , en faite mois j'avais mis PROCESS_QUERY_INFORMATION qui vise obntenir des info sur ce process or qu'il fallait mettre un SYNCHRONIZE pour se synchroniser avec l'état du process P2

Code:

---

1 2 3 4 5 6 7 8

UINT __cdecl ControlerThread( LPVOID pParameters ) { DWORD processID=GetPidByName("P2.exe");// j'obtient le PID du process P2 par une fonction prédéfinie GetPidByName HANDLE hP2=OpenProcess(SYNCHRONIZE ,FALSE, processID ); WaitForSingleObject(hP2,INFINITE); return 0; }

---