Wie behandelt man eine defekte Pipe (SIGPIPE) in Python?

Ich geschrieben habe, eine einfache multi-threaded-Spiel-server in python, erstellt einen neuen thread für jede client-Verbindung. Ich finde, dass jeder jetzt und dann, die server zum Absturz bringen, da ein broken-pipe/SIGPIPE Fehler. Ich bin mir ziemlich sicher, dass es passiert, wenn das Programm versucht zu senden eine Antwort zurück an client, dass ist nicht mehr vorhanden.

Was ist ein guter Weg, um damit umzugehen? Meine bevorzugte Lösung wäre, einfach schließen Sie das server-side-Verbindung zum client und bewegen, eher als beenden Sie das gesamte Programm.

PS: Diese Frage/Antwort beschäftigt sich mit dem problem in einer Allgemeinen Weise; wie konkret soll ich es lösen?

InformationsquelleAutor der Frage Adam Plumb | 2008-10-07

  1. 37

    Lesen, auf die versuchen: - Anweisung.

    try:
    # do something
except socket.error, e:
    # A socket error
except IOError, e:
    if e.errno == errno.EPIPE:
        # EPIPE error
    else:
        # Other error

    InformationsquelleAutor der Antwort S.Lott

  2. 48

    Angenommen, Sie benutzen die standard-socket-Modul, sollten Sie fangen die socket.error: (32, 'Broken pipe') Ausnahme (nicht IOError, wie andere vorgeschlagen haben). Dies wird in dem Fall erhoben, dass Sie ' ve beschrieben, d.h. senden/schreiben auf einen socket, für die die remote-Seite getrennt wurde.

    import socket, errno, time

# setup socket to listen for incoming connections
s = socket.socket()
s.bind(('localhost', 1234))
s.listen(1)
remote, address = s.accept()

print "Got connection from: ", address

while 1:
    try:
        remote.send("message to peer\n")
        time.sleep(1)
    except socket.error, e:
        if isinstance(e.args, tuple):
            print "errno is %d" % e[0]
            if e[0] == errno.EPIPE:
               # remote peer disconnected
               print "Detected remote disconnect"
            else:
               # determine and handle different error
               pass
        else:
            print "socket error ", e
        remote.close()
        break
    except IOError, e:
        # Hmmm, Can IOError actually be raised by the socket module?
        print "Got IOError: ", e
        break

    Beachten Sie, dass diese Ausnahme wird nicht immer ausgelöst werden, die auf das erste schreiben an einen geschlossenen socket - mehr in der Regel das zweite schreiben (es sei denn, die Anzahl der bytes, die geschrieben sind in dem ersten schreiben der größer ist als der socket-Puffer-Größe). Sie brauchen, um beachten Sie dies bei Ihrer Bewerbung denkt, dass das remote-Ende erhalten die Daten aus dem ersten schreiben, wenn es möglicherweise bereits getrennt haben.

    Können Sie reduzieren die Inzidenz (aber nicht vollständig beseitigen) mit select.select() (oder poll). Prüfen Sie für die Daten bereit zum Lesen aus der peer vor, der versucht, eine zu schreiben. Wenn select berichtet, dass es Daten zum Lesen aus der peer-Buchse, Lesen Sie es mit socket.recv(). Wenn dies eine leere Zeichenfolge zurück, die Gegenstelle hat die Verbindung geschlossen. Denn es gibt immer noch eine race-condition hier, werden Sie noch brauchen, zu fangen und behandeln der Ausnahme.

    Verdreht ist ideal für diese Art der Sache, aber es klingt wie Sie bereits geschrieben haben, ein gutes Stück code.

    InformationsquelleAutor der Antwort mhawke

  3. 3

    SIGPIPE (obwohl ich denke, vielleicht meinst du EPIPE?) tritt auf sockets, wenn Sie heruntergefahren Steckdose und dann die Daten an ihn zu senden. Die einfache Lösung nicht zu verschließen, den sockel herunter, bevor Sie versuchen, es zu senden Daten. Dies kann auch geschehen, auf den pipes, aber es klingt nicht wie das ist, was Sie erleben, da es ein Netzwerk-server.

    Können Sie auch nur für das band-aid-fangen Sie die Ausnahme in einigen top-level-handler in jedem thread.

    Natürlich, wenn Sie verwendet Verdreht statt und erzeugt einen neuen thread für jede client-Verbindung, würden Sie wahrscheinlich nicht dieses problem haben. Es ist wirklich schwer (vielleicht unmöglich, je nach Anwendung), um die Bestellung des nah-und schreib-Operationen korrigieren, wenn mehrere threads befassen sich mit den gleichen I/O-Kanal.

    InformationsquelleAutor der Antwort Glyph

  4. 0

    Ich vor der gleichen Frage. Aber ich behaupte, dass die gleichen code das nächste mal, es funktioniert einfach.
    Das erste mal brach es:

    $ packet_write_wait: Connection to 10.. port 22: Broken pipe

    Zweiten mal funktioniert es:

    [1]   Done                    nohup python -u add_asc_dec.py > add2.log 2>&1

    Ich denke, der Grund dafür könnte sein, über die aktuelle server-Umgebung.

    InformationsquelleAutor der Antwort yuan

  5. -3

    Meine Antwort ist sehr nah an S. Lott, außer ich würde noch mehr sein, insbesondere:

    try:
    # do something
except IOError, e:
    # ooops, check the attributes of e to see precisely what happened.
    if e.errno != 23:
        # I don't know how to handle this
        raise

    wobei "23" ist die Fehler-Nummer erhalten Sie von EPIPE. Auf diese Weise werden Sie nicht versuchen, zu behandeln, Berechtigungen ein Fehler oder irgendetwas anderes, Sie sind nicht ausgestattet für.

    InformationsquelleAutor der Antwort Kirk Strauser

Schreibe einen Kommentar