atexit, oder wie man Python-Dienste nicht beenden sollte

Wer schon einmal einen Dienst mit Python realisiert hat, wird bereits vor der Aufgabe gestanden haben die Aufgaben die er verrichtet sauber und geordnet zu beenden. Python bietet einem hier vielerlei Lösungen an, darunter auch das atexit Modul. Für schnelle und simple Aufräum-Arbeiten ist dieses Modul wunderbar geeignet, nicht jedoch wenn Thread-Synchronisation und externe Kommunikation im Spiel ist. Warum das so ist und was die saubere Alternative ist, darum geht es heute in diesem Blogpost.
Wie der Name des Moduls und dessen Dokumentation bereits sagt, werden registrierte Routinen ausgeführt kurz bevor der Interpreter angehalten wird. Klingt erst einmal nicht besonders problematisch, ist es doch gerade was man haben möchte. Und es funktioniert sogar, solange keine Threads laufen. Dann werden die registrierten Routinen nicht aufgerufen. Das liegt daran, dass “normale” Threads explizit beendet werden müssen, sonst verhindern diese den Stopp des Interpreters. Damit das nicht passiert, kommt man möglicherweise auf folgende Idee:

t = threading.Thread(target=func)
t.daemon = True  # Avoids that python hangs during shutdown
t.start()

Ganz schlecht. Das mag möglicherweise den gewünschten Effekt haben und die Aufräum-Routinen können ihre Arbeit verrichten. Aber tatsächlich ist dies nur eine Lösung für ein Symptom, das eigentliche Problem ist noch immer nicht gelöst. Das wird einem spätestens klar, wenn es nicht mehr nur darum geht Threads zu beenden, sondern auch noch mit anderen über das Netzwerk verbundenen Diensten/Klienten eine saubere Unterbrechung der Kommunikation einzuleiten.
Denn was genau passiert wenn der Interpreter angehalten wird?

  1. Der MainThread wird sofort angehalten
  2. Offene File-Handles werden geschlossen
  3. Es wird gewartet dass alle nicht-Daemon Threads beendet wurden
  4. Die atexit-Routinen werden ausgeführt
  5. Garbage Collection
  6. Der Prozess wird beendet

Der zweite Punkt lässt einige vielleicht bereits aufhorchen, denn sockets sind nichts anderes als File-Handles. Wer nun immer noch denkt er könne in einem daemon-Thread die Netzwerk-Kommunikation mit seinem Gegenüber sauber beenden, ist auf dem Holzweg. Zum Zeitpunkt zu dem die atexit-Routinen laufen, sind bereits alle sockets unwiderruflich geschlossen.
Angenommen der Stopp des Dienstes wird ganz normal über SIGTERM initiiert, so könnte man nun alle atexit-Routinen in einen Signal-Handler verlagern. Dadurch würden sie laufen noch bevor der Interpreter angehalten wird, allerdings kommt man so sehr schnell wieder in die Bredouille, je nachdem welche Art von Arbeit der MainThread verrichtet. Denn da Signal-Handler asynchron im MainThread ausgeführt werden, ist das Risiko für ein Deadlock sehr groß. Kommen wir also zur erwähnten, sauberen Alternative: Feuer mit Feuer bekämpfen.
Was vormals in etwa so aussah:

class SomeDaemon:
    def start():
        # ...
        signal.signal(signal.SIGTERM, self._sigterm)
        atexit.register(self._atexit)
        # ...
    def _sigterm(self, signum, frame):
        sys.exit(0)
    def _atexit(self):
        # Alle Aufräum-Arbeiten

Kann ganz einfach, mit durchschlagendem Erfolg, so umgebaut werden:

class SomeDaemon:
    def start():
        # ...
        signal.signal(signal.SIGTERM, self._sigterm)
        atexit.register(self._atexit)
        # ...
    def _sigterm(self, signum, frame):
        threading.Thread(target=self._cleanup, name='CleanupThread').start()
    def _cleanup(self):
        # Komplexe Aufräum-Arbeiten
    def _atexit(self):
        # Einfache Aufräum-Arbeiten

Der “CleanupThread” sollte selbstverständlich keine Arbeit verrichten die unkontrolliert blockt. Denn dann sieht das ganze am Ende wieder so aus:

    def _sigterm(self, signum, frame):
        t = threading.Thread(target=self._cleanup, name='CleanupThread')
        t.daemon = True
        t.start()

Und der ganze Spaß geht von vorne los..

Johannes Meyer
Johannes Meyer
Developer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.

Asynchroner Webserver in Python mit gevent

Was ist gevent?
gevent ist eine Koroutinen-basierte Netzwerkbibliothek für Python basierend auf libev und greenlet.
greenlets sind leichtgewichtige Koroutinen, die im Prozess des ausführenden Programms laufen, aber nebenläufig ausgeführt werden. Im Gegensatz dazu werden beim Multitasking, Threads vom Betriebssystem geplant, die echt gleichzeitig laufen.
Parallelität vs Nebenläufigkeit
Zwei Aufgaben heißen nebenläufig, wenn sie voneinander unabhängig, in einem sich überschneidenden Zeitfenster, abgearbeitet werden. Dabei müssen diese nicht unbedingt echt gleichzeitig bearbeitet werden.
Zwei Aufgaben werden parallel bearbeitet, wenn sie unabhängig voneinander und zur gleichen Zeit ausgeführt werden.
“Benchmark”
Um die Performance von gevent zu vergleichen (Achtung nicht repräsentativ), lassen wir es gegen Twisted und wsgiref antreten. Die drei Kandidaten starten jeweils einen WSGI Server auf http://127.0.0.1:8088/ und beantworten jede Request mit “HTTP/1.0 200 OK”.
Mit dem Apache HTTP server benchmarking tool lassen wir 30 Sekunden (maximal 50 000 Requests) 1 000 Requests parallel laufen um vergleichen zu können, welche Implementation, die meisten Requests pro Sekunde beantwortet:

ab -r -c 1000 -t 30 http://127.0.0.1:8088/

Twisted

#!/usr/bin/python
from twisted.web import server
from twisted.web.wsgi import WSGIResource
from twisted.internet import reactor
def handle_request(env, start_response):
    status = '200 OK'
    output = 'The Output'
    response_headers = [('Content-Type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    return [output]
if __name__ == '__main__':
    resource = WSGIResource(reactor, reactor.getThreadPool(), handle_request)
    reactor.listenTCP(8088, server.Site(resource))
    reactor.run()

Requests per second: 1093.40 [#/sec] (mean)
Time per request: 0.915 [ms] (mean, across all concurrent requests)

wsgiref

#!/usr/bin/python
from wsgiref.simple_server import make_server
def handle_request(env, start_response):
    status = '200 OK'
    output = 'The Output'
    response_headers = [('Content-Type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    return [output]
if __name__ == '__main__':
    wsgiserver = make_server('', 8088, handle_request)
    wsgiserver.serve_forever()

Requests per second: 1610.80 [#/sec] (mean)
Time per request: 0.621 [ms] (mean, across all concurrent requests)

gevent

#!/usr/bin/python
from gevent.wsgi import WSGIServer
def handle_request(env, start_response):
    status = '200 OK'
    output = 'The Output'
    response_headers = [('Content-Type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    return [output]
if __name__ == '__main__':
    WSGIServer(('', 8088), handle_request, spawn=None).serve_forever()

Requests per second: 2121.29 [#/sec] (mean)
Time per request: 0.471 [ms] (mean, across all concurrent requests)

Die Einfachheit des Benchmark lässt natürlich keine Rückschlüsse auf Applikationen in der echten Welt zu. gevent ist aber definitiv einen Blick wert, wenn es um asynchrone Socket-Programmierung geht.

Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.