Das deutsche Python-Forum

Habe einen Windows-Dienst geschrieben. Mit der .py Datei klappt alles: Installation, Starten, Stoppen. Nachdem "Packen" mit py2exe geht zwar noch die Installation (myservice.exe --startup auto install), aber der Dienst kann nicht gestartet werden (net start myservice). Fehler:

Der Dienst reagiert auf die Kontrollfunktion nicht.

Sie erhalten weitere Hilfe, wenn Sie NET HELPMSG 2186 eingeben.

Wieso gibt's mit der .exe Probleme und v.a. wie kann ich das beheben?

*push*

Hum, ich komm da nicht weiter, finde auch keine sonstigen Fehler. Was genau macht eigentlich die pythonservice.exe? Ist die vergleichbar mit srvany.exe und regsrv.exe aus dem Windows Resource-Kit?

Ich hab das Gefühl, dass die pythonservice.exe als Dienst läuft und Python-Scripte als Dienst registriert. Entweder startet sie dafür den Python-Interpreter oder der steckt in der pythonservice.exe selbst schon mit drin…

Habe heraus gefunden, dass es wahrscheinlich nicht am Modul `win32service` liegt, sondern vielleicht an `win32com.client`, da ich darüber laufende Windows-Prozesse auslese.

Da ich meinen Windows-Dienst mittels `pythonservice.exe` nicht als .exe zum Laufen bekommen habe, habe ich alles umgebaut und wollte den manuellen Weg über srvany.exe und instsrv.exe aus dem Windows Resource Kit gehen.

Nachdem ich alles in eine .exe gebacken bekommen habe, läuft die .exe als Standalone-Programm einwandfrei. Dann habe ich srvany.exe mit der instsrv.exe nach Anleitung als Dienst registriert und meine .exe gestartet. Alles endet in demselben Fehler wie vorher.

Um auszuschließen, dass ich bei srvany.exe und instsrv.exe einen Fehler gemacht habe, habe ich eine winzige Test .exe geschrieben, die darüber wunderbar als Windows-Dienst läuft. Es muss also an meinem Code liegen, denke ich. Irgendwas anderes verursacht das Problem, dass der Dienst nicht gestartet werden kann.

Weiß jemand Rat?

Hallo droptix!

Muss es denn *py2exe* sein? Warum lässt du es nicht als normales Python-Modul laufen? So wie hier:

http://www.python-forum.de/topic-8422.html

Aber Vorsicht! Entweder *py2exe* oder so wie im Beispiel gezeigt. Beides lässt sich nicht mischen, da py2exe sein eigenes Süppchen kocht und einfach das Python-Modul über einen Wrapper aufruft.

Und denke immer daran, dass ein Windows-Dienst nicht die gleiche Arbeitsumgebung wie du hat. -- Keine gemappten Laufwerke; wenig gesetzte Umgebungsvariablen; evt. nicht gesetzte PATH-Variable; usw.

mfg
Gerold

gerold hat geschrieben:Hallo droptix!

Muss es denn *py2exe* sein? Warum lässt du es nicht als normales Python-Modul laufen? So wie hier:

http://www.python-forum.de/topic-8422.html

^ Das war ja Versuch Nummer eins. Allerdings muss ich den Dienst auf einige hundert Maschinen verteilen, bei denen kein Python installiert ist. Daher wollte ich den `win32service` Dienst in eine .exe packen, aber so funktionierte das Programm nicht mehr.

gerold hat geschrieben:Aber Vorsicht! Entweder *py2exe* oder so wie im Beispiel gezeigt. Beides lässt sich nicht mischen, da py2exe sein eigenes Süppchen kocht und einfach das Python-Modul über einen Wrapper aufruft.

Na startet py2exe nicht einfach die python2x.dll als Interpreter und ruft die eingekapselte .pyo Datei darüber auf? Klar dass man nicht beides mischen sollte… ich brauch auch nur einen gängigen Weg.

gerold hat geschrieben:Und denke immer daran, dass ein Windows-Dienst nicht die gleiche Arbeitsumgebung wie du hat. -- Keine gemappten Laufwerke; wenig gesetzte Umgebungsvariablen; evt. nicht gesetzte PATH-Variable; usw.

Wo kann man solche Einschränkungen mal nachlesen? Mein Tool macht nix Besonderes, aber es wäre zukünftig schon interessant zu wissen, was nicht geht. Und diese Einschränkungen gelten sowohl für `pythonservice.exe` als auch für `srvany.exe`?

Um gleich nochmal auf `pythonservice.exe` zurück zu kommen: Ist die nicht vergleichbar mit der `srvany.exe`?

--

P.S. Mein Programm läuft jetzt als .exe über `srvany.exe`. Allerdings auch erst nachdem ich das Modul `threading` rausgeschmissen habe. Damit gab's noch irgendwelche komischen Probleme beim Aufruf von COM-Objekten (mittels `win32com.client`). Nach einigem Googlen bin ich drauf gestoßen, dass typischerweise `threading` diesen Fehler auslöst.