Seite 1 von 1

Python Scrypt als Daemon im Hintergrund?

Verfasst: Samstag 17. Januar 2009, 09:05
von kromonos
Ist es möglich, ein Python Script unter Linux als Daemon im hintergrund laufen zu lassen? .. Bzw. ein Script so zu schreiben, dass es sich selbt, wie z.B. der eggdrop Bot, in den Hintergrund läd?

Ich bastel da nämlich an einem MUC Bot, der in Python geschrieben ist. Allerdings muss ich den entweder immer in einem Screen aufrufen oder auf einer anderen tty Konsole und die dann eingeloggt lassen -.- Und das nervt mich auf dauer doch ein wenig ..

Re: Python Scrypt als Daemon im Hintergrund?

Verfasst: Samstag 17. Januar 2009, 12:15
von dev
kromonos hat geschrieben:Ist es möglich, ein Python Script unter Linux als Daemon im hintergrund laufen zu lassen?
http://pypi.python.org/pypi/bda.daemon/1.1.1

http://twistedmatrix.com/trac/browser/t ... ix.py#L156

Ciao,
dev

Verfasst: Samstag 17. Januar 2009, 13:07
von kromonos
Danke für die antwort dev ..
Ich werds mir auch direkt mal angucken ^^

Verfasst: Samstag 17. Januar 2009, 14:11
von Darii
Oder auch http://code.activestate.com/recipes/66012/ , mit Erklärungen

Verfasst: Samstag 17. Januar 2009, 14:30
von kromonos
Darii hat geschrieben:Oder auch http://code.activestate.com/recipes/66012/ , mit Erklärungen
Sehr schön :)
Das hilft mir sehr gut weiter :)

Verfasst: Samstag 17. Januar 2009, 15:58
von lunar
Du solltest die Kommentare beachten. Für einen einfachen Dienst benötigt man den doppelten Fork nicht, das Schließen der Standarddatenströme dagegen ist durchaus empfehlenswert, wird aber erst in den Kommentaren erwähnt.

Verfasst: Sonntag 2. August 2009, 09:16
von burli
Hi, ich möchte das Thema nochmal ausgraben, weil ich gerade etwas ähnliches machen möchte. Und zwar möchte ich ein Python Script schreiben, das als normaler Dienst unter Linux läuft, den man mit start, stop, restart usw steuern kann.

Ich weiß bisher nur, dass man dafür ein Script verwendet und das man ein Beispiel dafür unter /etc/init.d/skeleton findet. Ich bin aber noch nicht dahinter gekommen, wie man das Python Script entsprechend programmieren muss und wie man das Skeleton anpassen muss

Hat da jemand vielleicht sogar ein Beispiel?

Verfasst: Sonntag 2. August 2009, 09:48
von Leonidas
Also unter Debian läuft das alles durch ``start-stop-daemon``, und da muss man optimalerweise eine PID-Datei schreiben, und auf ein paar Signale reagieren (SIGTERM, SIGHUP) und das ist eigentlich auch schon alles damit ein Daemon mit dem init-System zusammenspielt.

Verfasst: Sonntag 2. August 2009, 09:52
von burli
Hm, läuft das unter Suse/Red Hat anders? Dachte, das wäre einheitlich unter Linux

Verfasst: Sonntag 2. August 2009, 10:49
von Leonidas
Da ``start-stop-daemon`` ein Debian-spezifisches Tool ist, wird das wohl woanders leicht unterschiedlich sein (die grobe Essenz des SysV Init Systems bleibt natürlich die gleiche).

Verfasst: Sonntag 2. August 2009, 11:10
von burli
Ok, das heißt, dass das oben beschriebene System für Linux im allgemeinen gilt. Nur die Steuerung des start-stop-deamon ist Debian spezifisch

Verfasst: Sonntag 2. August 2009, 12:14
von jerch
Ok, das heißt, dass das oben beschriebene System für Linux im allgemeinen gilt. Nur die Steuerung des start-stop-deamon ist Debian spezifisch
Genau, Grundgerüst ist quasi dasselbe (Skripte in /etc/init.d, symlinks unter rcX.d je nach Start-/Stoppriorität und runlevel), Unterschiede liegen dann im Detail:
  • SuSE/RedHat haben versucht, das zu standardisieren, daher unterliegt das Skript gewissen Konventionen im oberen Kommentarteil (Teil der LSB-Spec), wird aber inzwischen von den großen Distributionen und deren Dienstetools ebenfalls beachtet (siehe INIT INFO Sektion)
  • SuSEnahe haben unter den rc-Ordnern getrennte Start-/Stoplinks, Debianabkömmlinge kennen nur einen Link und lösen das über die INIT INFO auf
  • SuSE legt unter /usr/sbin symlinks zu den Skripten an (rcNameDesSkriptes), ist z.T. für frühe Dienste Pflicht (wegen Mountstatus des root-FS, weiß nicht mehr genau, was da war)
Für SuSE würde ich ausgehend vom Skeleton das Skript schreiben. Hast Du hier alle Abhängigkeiten richtig eingetragen, kümmert sich 'insserv' um die Erstellung der ganzen Symlinks und die Start-/Stopreihenfolge.

Ubuntu will mit upstart das SysV-Init-Modell ganz verlassen, nutzt es derzeit aber immernoch (innerhalb von upstart).