Das deutsche Python-Forum

veers hat geschrieben:Zum Glück ist signals keine globale Variable! *duck*

veers hat geschrieben:Zum Glück ist signals keine globale Variable! *duck*

HWK hat geschrieben:1. Ich dachte, Klassen dienen dazu, Methoden und Attribute zu kapseln. Warum dann signal_handler als Funktion? Oder ist es üblich, Python-Klassen wie C-Structs allein zur Speicherung von Daten zu verwenden?

HWK hat geschrieben:2. signals ist ja zumindest global, wenn vielleicht auch keine Variable. Ist das denn besser als canceled und reload_it gleich als globale Variablen zu verwenden?

Leonidas hat geschrieben:

Code: Alles auswählen

import signal, time

class Listener(object):
    def complain(self, signum, frame):
        self.loop = False
    
    def run(self):
        signal.signal(signal.SIGHUP, self.complain)
        runs = 0
        while True:
            runs += 1
            print "Starting run %d" % runs
            self.loop = True
            while self.loop:
                time.sleep(1)

Listener().run()

Python hat geschrieben:Traceback (most recent call last):
File "server.py", line 17, in ?
Listener().run()
File "server.py", line 8, in run
signal.signal(signal.SIGHUP, self.complain)
AttributeError: 'module' object has no attribute 'SIGHUP'

NSIG = 23
SIGABRT = 22
SIGBREAK = 21
SIGFPE = 8
SIGILL = 4
SIGINT = 2
SIGSEGV = 11
SIGTERM = 15
SIG_DFL = 0
SIG_IGN = 1

signal Dokumentation hat geschrieben:All the signal numbers are defined symbolically. For example, the hangup signal is defined as signal.SIGHUP; the variable names are identical to the names used in C programs, as found in <signal.h>.

droptix hat geschrieben:Kann mir wer weiter helfen, denn ich finde kein SIGHUP?

In [1]: import signal

In [2]: signal.
signal.NSIG                 signal.SIGPOLL              signal.SIGUSR1              signal.__name__
signal.SIGABRT              signal.SIGPROF              signal.SIGUSR2              signal.__new__
signal.SIGALRM              signal.SIGPWR               signal.SIGVTALRM            signal.__reduce__
signal.SIGBUS               signal.SIGQUIT              signal.SIGWINCH             signal.__reduce_ex__
signal.SIGCHLD              signal.SIGRTMAX             signal.SIGXCPU              signal.__repr__
signal.SIGCLD               signal.SIGRTMIN             signal.SIGXFSZ              signal.__setattr__
signal.SIGCONT              signal.SIGSEGV              signal.SIG_DFL              signal.__str__
signal.SIGFPE               signal.SIGSTOP              signal.SIG_IGN              signal.alarm
signal.SIGHUP               signal.SIGSYS               signal.__class__            signal.default_int_handler
signal.SIGILL               signal.SIGTERM              signal.__delattr__          signal.getsignal
signal.SIGINT               signal.SIGTRAP              signal.__dict__             signal.pause
signal.SIGIO                signal.SIGTSTP              signal.__doc__              signal.signal
signal.SIGIOT               signal.SIGTTIN              signal.__getattribute__
signal.SIGKILL              signal.SIGTTOU              signal.__hash__
signal.SIGPIPE              signal.SIGURG               signal.__init__

droptix hat geschrieben:gibt es Scripts, um ein Python-Programm als Dienst zu installieren - wobei das Script selbst entscheidet unter welchem Betriebssystem welche Maßnahmen zu treffen sind? Also unter Unix über init-Script und unter Windows über die pywin32-Extensions?

gerold hat geschrieben:Unter Linux reagierst du auf die zwei/drei Signale, kümmerst dich darum, dass beim Starten ein PID-File angelegt wird, beim Beenden das PID-File wieder gelöscht wird und legst ein Init-Skript an. Fertig!

gerold hat geschrieben:Unter Windows ist das schon ein wenig komplizierter und meine persönliche Erfahrung damit ist, dass ein Dienst unter Windows sehr viel schwerer zu debuggen ist. Es kahm schon vor, dass ich Tage brauchte um einen Dienst für Windows so zu programmieren, dass dieser auch anstandslos auch unter den 40 verschiedenen Windows-Clients eines Kunden lief und sich auch schön mit Bordmitteln beenden und neu starten lies.

gerold hat geschrieben:Zumindest bekommst du mit ``sys.platform`` raus auf welchem Betriebssystem dein Programm läuft.

droptix hat geschrieben:Wer legt eigentlich das PID-File an -> mein Programm oder das Init-Script? Was steht da drin, ich nehme an einfach nur die Prozess-Id? Wo muss das PID-File liegen?

droptix hat geschrieben:Nun ist das nicht gerade elegant, daher finde ich die pywin32-Geschichte sauberer und besser. Dort möchte ich mich reinfitzen...

droptix hat geschrieben:Wer legt eigentlich das PID-File an -> mein Programm oder das Init-Script? Was steht da drin, ich nehme an einfach nur die Prozess-Id? Wo muss das PID-File liegen?

Leonidas hat geschrieben:Praktisch hast du allerdings das Problem, wenn du im Init-Skript das PID-File anlegst dass das Programm sofort danach sterben kann (ImportError oder so), du also ein PID-File hast, dessen Prozess tot ist.

droptix hat geschrieben:

Leonidas hat geschrieben:Praktisch hast du allerdings das Problem, wenn du im Init-Skript das PID-File anlegst dass das Programm sofort danach sterben kann (ImportError oder so), du also ein PID-File hast, dessen Prozess tot ist.

Das passiert doch aber auch, wenn das Programm das PID-File anlegt und danach stirbt... es räumt ja keiner auf, richtig? Daher ist mir noch nicht klar, wie sich das vermeiden ließe...