[..] Execution depuis un service

[ricky]

Hello,

j'ai fait un programme que je lance en tant que service. Ce service est chargé de relancer un programme s'il se ferme (watchdog), mais j'ai un petit problème.

Quand je lance le programme, il se lance en tant que le fils du service. Donc si je supprime le service, l'application est tuée. Est-il possible de lancer le programme en tant que le fils d'explorer.exe?

Merci d'avance pour votre aide.

[TopXm]

Salut

De mémoire tu dois pouvoir configurer WatchDog pour qu'il reste toujours actif non ?

Vu son rôle c'est pas plus mal qu'il le soit non

sinon voir peut-être la fonction SetParent

Code : Tout sélectionner

DllCall($user32, "str", "SetParent", "HWnd", $HwndP, "HWnd", $HwndC)

[mikell]

j'ai fait un programme que je lance en tant que service. (.....) si je supprime le service, l'application est tuée.

Heu ben c'est normal non ?

[ricky]

@TopXm : je vois pas comment faire, tu peux me donner un exemple concret?

@mikell : Je ne sais pas, mais j'aimerais le rendre indépendant. En cas de désinstallation ou crash du service, l'application ne serait pas touchée.

[mikell]

C'est que je ne comprends pas bien...
Si service = programme1 , pour surveiller programme2, c'est normal que programme1 se ferme avec le service
Pour que programme1 soit indépendant du service il faudrait un service indépendant qui lance programme1 pour surveiller programme2, ça fait un peu usine à gaz, pourquoi ne pas simplement faire 2 programmes qui se surveillent mutuellement ?

[ricky]

Non, programme 1 est le programme principal (dont je n'ai pas les sources).
Le service est le programme 2.

Si pour cause d'un problème le programme 1 viendrait à fermer, le 2 (service) relance le 1, mais j'aimerais qu'il le lance en tant que fils du explorer.exe et non en tant que fils du service. Est-ce plus clair?

[mikell]

Est-ce plus clair?

Heu...
Donc si le 2(service) se ferme, alors le 1 (principal) se ferme aussi, c'est ça ?

en tant que fils du explorer.exe

Peut-être le lancer avec un ShellExecute (puisque explorer gère le shell) ou par un raccourci ferait l'affaire
ça serait possible de voir le code du script de surveillance ?

[ricky]

Si le programme 1 est en fils du 2 (service) si on désinstalle le service, le 1 va se fermer et de manière brutale.

Pour le code, ça va être dur, je l'ai oublié au boulot, mais il est simple, c'est une boucle infinie et dans cette boucle on lance le programme (basé sur l'UDF service).

Pour la manière de le lancer, le shellexecute ne marche pas, le RunAs est celui qui marche le mieux et je le lance avec un utlilisateur admin.

J'ai essaie avec Run(@ComSpec & " /c " & 'commandName', "", @SW_HIDE) et comme command name, je voulais essayer de faire un runas sous dos, mais ma commande n'a pas marché. J'ai du me tromper.

[mikell]

Si c'est RunAs qui marche alors ça peut vouloir dire qu'il y a un problème d'autorisations ce qui expliquerait la dépendance du soft au service
Passer par un service est vraiment nécessaire ? le même résultat pourrait être obtenu par un exe tournant en tâche de fond, les embêtements en moins

[ricky]

Non, non, il faut que ça soit un service. Le système le gère mieux.

[mikell]

Si le programme1 est lui-même lancé en tant que service par le programme2 y a rien à faire, à part peut-être utiliser la fonction Service_SetFailureActions dans l'udf
Si ça marche pas le + simple est de passer par un loader : le service lance le loader, qui lance le soft puis se ferme

[ricky]

Non, le programme 1 ne peut pas être lancé en service et même si c'était le cas, je n'en ai pas le droit.

En rajoutant un loader, je dois encore lancer un autre programme qui peut être source de problème.
Mais si j'utilise un loader, on va avoir le même problème, le loader va devenir le fils du service et le programme 1 le fils du loader ensuite je ferme le loader, que ce passe-t-il? Cette solution, n'arrange rien et je ne veux pas rajouter un intermédiaire inutile. Autant revenir à ma première demande, lancer le programme 1 en tant que le fils d'explorer.exe.

[mikell]

Mais si j'utilise un loader, on va avoir le même problème

Pas forcément, dans le loader tu peux mettre qqe chose comme ça :

Code : Tout sélectionner

$oShell = ObjCreate("shell.application")
$oShell.ServiceStop("service", true)
Do
Sleep(10)
Until $oShell.IsServiceRunning("service") = false
$oShell.ShellExecute("myexe.exe", "", $myexedirpath, "open", 1)  
          [color=#008000] ; pour la syntaxe : http://msdn.microsoft.com/en-us/library/gg537745.aspx [/color]
$oShell.ServiceStart("service", true)
$oShell = 0

[ricky]

Ok, pour cette ligne :

$oShell.ShellExecute("myexe.exe", "", $myexedirpath, "open", 1)

Mais tu fais quoi avec le reste, tu peux traduire? Je ne vois pas ce que viens faire les commandes pour le service.

[mikell]

le loader va devenir le fils du service et le programme 1 le fils du loader

c'est un test à essayer, le loader ferme le service, lance l'application, puis relance le service (aussi bien, ça peut planter...)
De toute façon $oShell.ShellExecute est la seule manière de lancer un soft en tant que "fils d'explorer"
Mais je pense que c'est une fausse piste, le souci vient certainement de la config du service et des autorisations
A moins qu'il n'existe tout simplement pas de solution