Wie deets schon sagte, ist das keine gute Idee bzw. widerspricht den UNIX-Dämon-Erwartungen. Die PID-Datei "gehört" dem Dämon-Prozess und sollte auch so behandelt werden (Dämon kümmert sich selbst um Erzeugung und Entfernung dergleichen). Eine PID-Datei enthält klassischerweise nichts weiter als die PID. Wenn Du Bsp. 2 umsetzt ist das "Locking" des Dämon-Prozesses gewährt, für QProcess müsstest Du das halt wie gesagt zusätzlich implementieren.
Wenn Du jetzt doch zusätzliche Informationen neben SIGTERM/SIGKILL mit dem Dämon austauschen willst, läufts halt auf eine IPC hinaus. Der simpelste Fall wäre die Nutzung einer Datei mit Konfigurationseinstellungen. Klassischerweise würde man hier davon ausgehen, das config-Dateien zum Start des Dämons ausgelesen werden bzw. über ein benutzerdefiniertes Signal ein "reload" der Konfigurationsdateien den Dämon zur Übernahme der geänderten Einstellungen bringen. Letzteres erfordert allerdings ein erweitertes Signalhandling im Dämon-Prozess, was alles andere als trivial ist.
Um das Ganze abzukürzen - vergiss Signalhandling - Du kannst eine config-Datei verwenden, wie Du selbst gesagt hast, bitte allerdings verschieden von der PID-Datei. Diese config-Datei wird nun vom GUI-Prozess beschrieben und vom Dämon in regelmäßigem Abstand geprüft bzw. gelesen. Die Prüfung seitens des Dämon-Prozesses könnte z.B. die mtime der Datei sein.
Die Einfachheit dieses Ansatzes hat ein paar Nachteile:
- Dämon muß config-Dateien pollen
- config-Datei muß gelockt werden von beiden Seiten im Falle des Zugriffes
- Responsivität des Dämons ist max. Polling-Frequenz der config-Datei
Sollten diese Nachteile ein
no go für Dich sein, mußt Du entweder ein echtes IPC vorhalten oder mit Signalhandling innerhalb des Dämons arbeiten. Beides ist allerdings sehr aufwändig, kA ob in Deinem Falle gerechtfertigt.
Zu Deiner konkreten Frage:
EmaNymton hat geschrieben:Ist es nicht das einfachste, wenn ich in der cfg-Datei auch die pid vom daemon-Prozess speichere, wenn er läuft. Dann könnte die UI doch auf diese pid zugreifen und den Prozess darüber killen. Ist das so sauber umsetzbar?
Das geht, sauber ist es nicht (siehe oben). Mir scheint, Dir ist die Funktionsweise von Bsp. 2 nicht ganz klar. Worüber Du Dir im Klaren sein musst, sind die verschiedenen Prozesse, die in Bsp. 2 gestartet werden. Wichtig hierfür sind die Aufrufe 'os.fork()' und die Beendigung der Prozesse über 'sys.exit()'. 'os.fork()' macht nichts weiter als einen neuen Prozess vom gegenwärtigen zu klonen (fork halt). Übertragen auf Bsp. 2 heisst das, dass Du plötzlich 2 Python-Prozesse mit demselben "Ausführungsstand" im Pythoncode hast, nämlich genau an der Stelle des 'os.fork()'-Aufrufs. Einziger Unterschied auf Prozessebene ist die PID, da der erste Child-Prozess PID 0 erhält während der Parent-Prozess eine PID von 0 verschieden hat. Mit if 'pid > 0: sys.exit(0)' wird der Parent-Prozess beendet, während der Child-Prozess weiterlebt (das Ganze passiert 2mal, um das Terminal und die "Elternschaft" des alten Prozesses loszuwerden, aber egal). Wichtig für Dich ist jetzt, was der Child-Child-Prozess macht, er ist nämlich der eigentliche Dämonprozess:
- STD-Dateihandler umleiten (wichtig für Terminaldetachment)
- PID-Datei schreiben (ja - ich bin ein aktiver Dämon)
- atexit-Regel: lösche PID-Datei, wenn ich beendet werde
- rufe run-Methode auf (der eigentliche Dämoncode)
Wie Du siehst, kümmert sich der Dämon selbst um die PID-Belange.
Der Code von Bsp. 2 ist eine ziemliche gute Übertragung des POSIX/UNIX-Standards für Dämons in Python. Diese Vorgehensweise solltest Du nicht leichtfertig ändern. Desweiteren liefert es mit der zweiten Datei eine Art start-/stop-Skript-Vorlage, welche allerdings für eine echte Systemintegration an die Systemgegebenheiten angepasst werde müsste (runlevel Skript). Genau hier wäre auch Dein Anknüpfungspunkt an den Dämonprozess - Du kannst die start/stop-API nutzen innerhalb Deines GUI-Programmes, entweder direkt (falls in Python) oder aber über das 2. Skript.
