McMillan Installer, Linux, und der Restart
Ich habe ein etwas komplexes Szenario, das ich im folgenden zu beschreiben versuche: /root/main [*] ist ein vom McMillan-Installer erzeugtes Python-Programm, das Module im folder /root/main/buildmain nachlädt. Das Programm hat einen separaten Thread, der alle 60 Sekunden folgendes macht: - mount auf /dev/fd0 - nachschaun, ob sich darauf eine Datei update.cmd befindet. - falls ja: diese Datei per os.spawnl(os.P_NOWAIT, "/usr/local/bin/python", "python", "/media/floppy/update.cmd") starten Dieses update.cmd ist ein Pythonscript, welches folgendes tut: - /-partition rw remounten - Laufendes /root/main beenden (stopsignal per sockets, warte 5 sekunden auf shutdown, falls nicht tot kille das programm) - Programmupdate einspielen - /root/main neu starten - 5 sekunden warten - /-partition ro remounten - umount /dev/fd0 Läuft /root/main noch nicht, kann mit update.cmd das Programm an sich hochgefahren werden, der start sollte also rein technisch korrekt sein. Wenn update.cmd aber aus /root/main heraus gestartet wird, kann nach dem einspielen des Updates /root/main nicht mehr gestartet werden: das Programm meldet "struct not found". Beendet man update.cmd und startet /root/main manuell, geht das - an der neuen Kopie kann es also nicht liegen. Folgendes habe ich bisher versucht: - os.spawnl(os.P_NOWAIT, "/root/main", "/root/main") -> gleiches verhalten - os.system("/root/main &") -> gleiches verhalten - os.chdir("/root") os.spawnl(os.P_NOWAIT, ...) -> gleiches verhalten. Erstaunlicherweise liefert im Kontext von update.cmd ein os.popen("ps -A|grep main").readlines() einen "main defunct" eintrag ??? Arg, bitte sagt mir daß das Unix-Prozesshandling nicht so bescheuert ist, Prozessleichen zu pflegen! (Das letzte mal habe ich sowas unter OS/2 gesehen, da wurden die Dinger "Zombie Prozesse" (sic, IBM doku says so) genannt) [*] Für Sicherheitsbedenkenträger: Der PC hat keine Tastatur / Bildschirm und ist in einem Tresor verschlossen. Disketten kann nur der Techniker einlegen, wenn jemand (2 Personen) den Tresor geöffnet hat. Der PC läuft ohne Netzwerk und bootet immer das gleiche Programm. _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerson Kurz wrote:
[...] Arg, bitte sagt mir daß das Unix-Prozesshandling nicht so bescheuert ist, Prozessleichen zu pflegen! (Das letzte mal habe ich sowas unter OS/2 gesehen, da wurden die Dinger "Zombie Prozesse" (sic, IBM doku says so) genannt) [...]
Zombies gibt es in der Tat unter Unix (die heissen auch so). Hier ist's rel. gut erklärt: http://www.latinomixed.com/article.php?story_id=129 Vielleicht hat es wirklich was mit fehlendem wait() zu tun?! -- Gerhard _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerson Kurz wrote:
Dieses update.cmd ist ein Pythonscript, welches folgendes tut:
- /-partition rw remounten - Laufendes /root/main beenden (stopsignal per sockets, warte 5 sekunden auf shutdown, falls nicht tot kille das programm) - Programmupdate einspielen - /root/main neu starten - 5 sekunden warten - /-partition ro remounten - umount /dev/fd0
Deine Beschreibung ist etwas konfus, da /root/main einmal als Programm, dann wieder als Verzeichnis daherkommt. Ich nehme an, dass das Programm tatsaechlich *in* diesem Verzeichnis liegt...
Erstaunlicherweise liefert im Kontext von update.cmd ein os.popen("ps -A|grep main").readlines() einen "main defunct" eintrag ???
Nichts erstaunliches dabei. man wait
Arg, bitte sagt mir daß das Unix-Prozesshandling nicht so bescheuert ist, Prozessleichen zu pflegen!
An Zombies unter unix wirst du dich gewoehnen muessen. Die sind wahrscheinlich um einiges aelter wie du! (Ok, nicht alle... ;) Solange der Elternprozess ein gestorbenes Kind nicht mit wait() oder waitpid() wieder "eingesammelt" hat, bleibt dessen Eintrag in der Prozessliste stehen. Andernfalls waere es fuer die Eltern nicht moeglich, die ordnungsgemaesse Beendung und den Rueckgabewert(!) ihrer Kinder zu ueberpruefen (unter Windows geht das z.B. nicht). Wenn der Elternprozess zuerst stirbt, dann "erbt" init dessen Kinder, welches sie dann automatisch mit wait() erloest. -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Zombies gibt es in der Tat unter Unix (die heissen auch so). Hier ist's rel. gut erklärt:
http://www.latinomixed.com/article.php?story_id=129
Vielleicht hat es wirklich was mit fehlendem wait() zu tun?!
<rant> Als jahrelanger OS72-Veteran habe ich ausgeprägte Vorurteile gegenüber Betriebssystemen, bei denen "Kill" etwas anderes als hirnloses Metzeln macht. (z.B. Signale schicken, die dann garantiert in irgendeiner popeligen Lib gefangen werden an die keiner gedacht hat). Wenn ich einen Prozess weghaben will, will ich ihn WEGHABEN und nicht "in den Papierkorb werfen". Das ist was für Weicheier, ich bin der HERR über meine Prozesse, bitteschön! Die Prozesse müssen vor meiner harten Hand zittern! Jawoll!!! *satanisches kichern* Und wenn ich root bin dann schon gleich sowieso! <rant> Zum Verständnis der Abhängigkeiten der Prozesse: Ich will *keinen* Kindprozess, ich will einen *eigenständigen* Prozess. main läuft main startet update update killt main update updated main update startet main update beendet sich main läuft So sollte das ablaufen. Update kann nicht auf die Beendigung von main warten! Egal, das ursächliche Problem hat evtl. damit zu tun, daß ich / ro-remounte. Und das geht so: starte main, warte 5 sekunden, "mount -n -o remount,ro /". Das ganze aus Angst vor dem Stromschalter und ext2, du weisst. Es stellt sich aber heraus, daß das compilierte Programm beim Start Module (aus den pkg-Dateien) nach /tmp extrahiert und von da nachlädt - ist beim start / noch ro, geht das net. Vielleicht lege ich /tmp auch in die beschreibbare Partition (ich habe 2 eingerichtet: eine spielwiese für logfiles, und eine ro für das Hauptprogramm, und natürlich eine swap). _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
On Tue, 10 Jun 2003, Gerson Kurz wrote:
Zum Verständnis der Abhängigkeiten der Prozesse: Ich will *keinen* Kindprozess, ich will einen *eigenständigen* Prozess. [...] So sollte das ablaufen. Update kann nicht auf die Beendigung von main warten!
Da hilft dir der alte "double-fork" Trick. Hier die Implementation aus der ROX-Lib von Thomas Leonard: ---> schnipp <--- from os import fork, _exit, execvp, waitpid def spawn(argv): """Run a new process and forget about it""" child = fork() if child == 0: # We are the child child = fork() if child == 0: # Grandchild try: execvp(argv[0], argv) except: pass print "Warning: exec('%s') failed!" % argv[0] _exit(1) elif child == -1: print "Error: fork() failed!" _exit(1) elif child == -1: print "Error: fork() failed!" waitpid(child, 0) ---> schnapp <--- -- Christopher Arndt [t] +49 (0)177-3072812 linux consulting [w] www.chrisarndt.de & edv training [e] chris.arndt@web.de _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
On Wed, 11 Jun 2003 01:50:55 +0200 (CEST), Christopher Arndt wrote:
child = fork() if child == 0:
...
elif child == -1: print "Error: fork() failed!" _exit(1)
Sorry, falls das jemand schon gepostet hat, aber Pythons os.fork() wirft eine Exception im Fehlerfall. Der Code ist mithin falsch, korrekter sieht's so aus: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012 Ciao, Jürgen -- Jürgen Hermann, Developer WEB.DE AG, http://webde-ag.de/ _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo *, (oder, "Hallo #?", wie wir ehemaligen Amiga-Heads sagen)
Der Code ist mithin falsch, korrekter sieht's so aus:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012
Vielen Dank für den Tip, damit hat der automatische Update funktioniert. Sorry daß ich erst jetzt antworte, ich bin a bisserl im Stress, und ausserdem hat das Wetter mein Hirn zu Mus eingekocht. Ach wenn es doch nur wieder Winter wäre... Wo ich gerade dabei bin: kennt ihr folgenden Telepolis-Artikel http://www.heise.de/tp/deutsch/inhalt/co/14997/1.html und die dazugehörige Webseite? Was wäre denn eurer Meinung nach eine "Killer-App" für Büdong? Ciao, Gerson _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (6)
-
Christopher Arndt -
Georg Mischler -
Gerhard Häring -
Gerson Kurz -
Gerson.Kurz＠t-online.de -
Juergen Hermann