Wie man SIGPIPE verhindert (oder richtig behandelt)

Ich habe ein kleines server-Programm, das akzeptiert verbindungen über eine TCP-oder lokalen UNIX-socket, liest einen einfachen Befehl und, je nach Befehl sendet eine Antwort. Das problem ist, dass der Kunde kein Interesse an der Antwort manchmal und beendet früh, so zu schreiben, dass die Buchse bewirkt, dass ein SIGPIPE und mein server crash. Was ist die best practice, um zu verhindern, dass der Absturz hier? Gibt es eine Möglichkeit zu überprüfen, ob die andere Seite der Zeile ist noch nicht zu Ende gelesen? (wählen Sie() scheint nicht zu funktionieren hier, wie Sie das immer sagt der socket schreibbar ist). Oder sollte ich einfach nur fangen die SIGPIPE mit einem handler und es ignorieren?

InformationsquelleAutor der Frage jkramer | 2008-09-20

  1. 199

    Dass Sie in der Regel ignorieren die SIGPIPE und verarbeiten Sie den Fehler direkt im code. Dies ist, weil die signal-Handler in C haben viele Einschränkungen auf, was Sie tun können.

    Den meisten portablen Weg, dies zu tun ist, um die SIGPIPE handler SIG_IGN. Dies wird verhindern, dass ein socket oder eine pipe zu schreiben, verursacht einen SIGPIPE signal.

    Ignorieren die SIGPIPE signal, verwenden Sie den folgenden code:

    signal(SIGPIPE, SIG_IGN);

    Wenn Sie mit der send() anrufen, eine andere Möglichkeit ist die Verwendung des MSG_NOSIGNAL option, die die SIGPIPE Verhalten aus-auf einer pro-call-basis. Beachten Sie, dass nicht alle Betriebssysteme unterstützen die MSG_NOSIGNAL Flagge.

    Schließlich, Sie möchten möglicherweise auch die SO_SIGNOPIPE socket-flag, das gesetzt werden kann, mit setsockopt() auf einigen Betriebssystemen. Dies wird verhindern, dass SIGPIPE wird verursacht, indem Sie schreibt, nur um die buchsen, die es gesetzt ist.

    InformationsquelleAutor der Antwort dvorak

  2. 139

    Andere Methode ist das ändern der Steckdose, so wird es nie SIGPIPE erzeugt, die auf write(). Das ist bequemer, in Bibliotheken, wo Sie nicht möchten, könnte eine Globale signal-handler für den SIGPIPE.

    Auf den meisten BSD-basierten (MacOS, FreeBSD...) Systeme, (vorausgesetzt, Sie sind mit C/C++), kann man dies mit:

    int set = 1;
setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int));

    Mit diesem in der Wirkung, statt den SIGPIPE-signal wird generiert, EPIPE zurückgegeben werden.

    InformationsquelleAutor der Antwort user55807

  3. 106

    Ich bin super spät zur party, aber SO_NOSIGPIPE ist nicht tragbar, und möglicherweise nicht auf Ihrem system funktionieren (es scheint zu sein, ein BSD-Sache).

    Eine gute alternative, wenn Sie auf, sagen wir mal, ein Linux-system ohne SO_NOSIGPIPE wäre, um die MSG_NOSIGNAL Flagge auf Ihrem senden(2) - Aufruf.

    Beispiel ersetzen write(...) durch send(...,MSG_NOSIGNAL) (siehe nobar's Kommentar)

    char buf[888];
//write( sockfd, buf, sizeof(buf) );
send(    sockfd, buf, sizeof(buf), MSG_NOSIGNAL );

    InformationsquelleAutor der Antwort sklnd

  4. 28

    In diesem post ich beschrieb mögliche Lösung für Solaris Fall, wenn weder SO_NOSIGPIPE noch MSG_NOSIGNAL verfügbar ist.

    Stattdessen haben wir vorübergehend unterdrücken SIGPIPE in den aktuellen thread, der ausgeführt wird, code für die Bibliothek. Hier ist, wie dies zu tun: zum unterdrücken von SIGPIPE wir zuerst prüfen, ob es ausstehend ist. Wenn Sie es tut, dies bedeutet, dass es blockiert, in diesem thread, und wir haben nichts zu tun. Wenn die Bibliothek generiert zusätzliche SIGPIPE, es wird zusammengeführt mit den anstehenden eins, und das ist ein no-op. Wenn SIGPIPE ist nicht anhängig dann sperren wir es in diesem thread, und auch überprüfen, ob es das schon war blockiert. Dann sind wir frei, zur Ausführung unserer schreibt. Wenn wir wieder SIGPIPE in seinen ursprünglichen Zustand, werden wir Folgendes tun: wenn SIGPIPE anhängig war ursprünglich, wir tun nichts. Ansonsten prüfen wir, ob es ist nun anhängig. Wenn es funktioniert (was bedeutet, dass Aktionen erzeugt eine oder mehrere SIGPIPEs), dann warten wir es in diesem thread, damit clearing seinen status aus (um dies zu tun, verwenden wir sigtimedwait() mit null timeout; dies ist zu vermeiden, blockiert in einem Szenario, in denen böswillige Benutzer gesendet SIGPIPE manuell, um den ganzen Prozess: in diesem Fall werden wir sehen, es aus, aber andere thread vielleicht handhaben Sie es vorher hatten wir eine änderung zu warten, bis es). Nach dem löschen des status "ausstehend" wir entsperren SIGPIPE in diesem thread, aber nur, wenn es nicht blockiert ursprünglich.

    Beispiel-code bei https://github.com/kroki/XProbes/blob/1447f3d93b6dbf273919af15e59f35cca58fcc23/src/libxprobes.c#L156

    InformationsquelleAutor der Antwort kroki

  5. 19

    Handle SIGPIPE Lokal

    Es ist normalerweise am besten, um den Fehler zu behandeln, die lokal anstatt in einer globalen signal-Ereignis-handler, da lokal haben Sie mehr Kontext zu dem, was Los ist und was den Rückgriff zu nehmen.

    Ich habe einen Kommunikations-layer in einer meiner apps, die erlaubt, dass meine app zur Kommunikation mit einem externen Zubehör. Wenn eine write-Fehler tritt auf, I throw und Ausnahme in der Kommunikations-Schicht und lassen Sie es Blase bis zu einem try-catch-block zum verarbeiten es dort.

    Code:

    Den code zu ignorieren, ein SIGPIPE-signal, so dass Sie verarbeiten kann es lokal ist:

    //We expect write failures to occur but we want to handle them where 
//the error occurs rather than in a SIGPIPE handler.
signal(SIGPIPE, SIG_IGN);

    Dieser code wird verhindern, dass das SIGPIPE-signal ausgelöst wird, aber du erhältst eine lese - /schreib-Fehler, wenn versucht, den socket zu verwenden, so dass Sie brauchen, um zu überprüfen, dass.

    InformationsquelleAutor der Antwort Sam

  6. 13

    Können Sie nicht verhindern, dass der Prozess am anderen Ende des Rohres zu verlassen, und wenn es beendet, bevor Sie fertig sind zu schreiben, Sie erhalten ein SIGPIPE-signal. Wenn Sie SIG_IGN das signal, dann ist dein schreiben zurück mit einem Fehler - und Sie brauchen, um beachten und darauf zu reagieren, dass Fehler. Nur fangen und ignorieren das signal in ein hf ist keine gute Idee-man muss beachten, dass die Pfeife ist inzwischen geschlossen und das Programm verändern das Verhalten, damit es nicht schreiben, um das Rohr wieder (denn das signal wird erzeugt, die wieder und wieder ignoriert, und Sie werde versuchen Sie es erneut, und der gesamte Prozess könnte noch ein lange Zeit und verbrauchen sehr viel CPU-Leistung).

    InformationsquelleAutor der Antwort Jonathan Leffler

  7. 4

    Oder sollte ich einfach nur fangen die SIGPIPE mit einem handler und es ignorieren?

    Ich glaube, dass richtig ist. Sie möchten wissen, Wann Sie das andere Ende geschlossen hat, Ihre Beschreibung und das ist, was SIGPIPE sagt Sie.

    Sam

    InformationsquelleAutor der Antwort Sam Reynolds

  8. 2

    Linux Handbuch sagte:

    EPIPE lokales Ende heruntergefahren wurde, auf einen Zusammenhang orientiert
    socket. In diesem Fall wird der Prozess auch erhalten ein SIGPIPE
    es sei denn, MSG_NOSIGNAL eingestellt ist.

    Aber für Ubuntu 12.04 ist es nicht Recht. Ich schrieb einen test für diesen Fall, und ich erhalten immer EPIPE withot SIGPIPE. SIGPIPE wird genereated wenn ich versuche zu schreiben, um die gleichen kaputten Buchse zweiten mal. So brauchen Sie nicht zu ignorieren, SIGPIPE, wenn dieses signal passiert, es heißt Logik-Fehler in Ihrem Programm.

    InformationsquelleAutor der Antwort talash

  9. 1

    Was ist die best practice, um zu verhindern, dass der Absturz hier?

    Entweder deaktivieren sigpipes als pro jeder oder fangen und ignorieren Sie den Fehler.

    Gibt es eine Möglichkeit zu überprüfen, ob die andere Seite der Zeile ist noch nicht zu Ende gelesen?

    Ja, verwenden Sie().

    wählen Sie() scheint nicht zu funktionieren hier, wie Sie das immer sagt der socket schreibbar ist.

    Müssen Sie auf die Lesen bits. Können Sie wahrscheinlich ignorieren die schreiben bits.

    Wenn die Gegenseite schließt die Datei verarbeiten, wählen Sie wird Ihnen sagen, dass es ist, Daten bereit zu Lesen. Wenn Sie gehen und Lesen, dass Sie wieder 0 Byte, das ist wie das Betriebssystem Ihnen mitteilt, dass das Datei-handle geschlossen wurde.

    Nur die Zeit, Sie können nicht ignorieren, das schreiben von bits ist, wenn Sie das senden von großen Mengen, und es ist ein Risiko, das andere Ende immer im Rückstand, die kann dazu führen, Ihre Puffer zu füllen. Wenn das passiert, dann versucht, zu schreiben, um die Datei-handle kann dazu führen, dass das Programm/thread zu sperren oder nicht. Testen wählen Sie vor dem schreiben schützen Sie, aber es gibt auch keine Garantie, dass das andere Ende gesund ist, oder dass Ihre Daten zu kommen.

    Beachten Sie, dass Sie erhalten ein sigpipe von close(), sowie beim schreiben.

    Schließen, spült jede gepufferte Daten. Wenn das andere Ende der bereits geschlossen wurde, schließen Sie dann fehl, und Sie erhalten ein sigpipe.

    Wenn Sie mit gepufferten TCPIP, dann das erfolgreiche schreiben bedeutet einfach nur Ihre Daten in die Warteschlange eingereiht wurde, zu senden, es bedeutet nicht, dass es gesendet wurde. Bis Sie sich erfolgreich in der Nähe nennen, wissen Sie nicht, dass Ihre Daten gesendet wurden.

    Sigpipe Ihnen sagt, etwas ist schief gegangen, es muss Ihnen nicht sagen, was oder was man dagegen machen sollte.

    InformationsquelleAutor der Antwort Ben Aveling

  10. -1

    Unter einem modernen POSIX-system (z.B. Linux), können Sie die sigprocmask() Funktion.

    #include <signal.h>

void block_signal(int signal_to_block /* i.e. SIGPIPE */ )
{
    sigset_t set;
    sigset_t old_state;

    //get the current state
    //
    sigprocmask(SIG_BLOCK, NULL, &old_state);

    //add signal_to_block to that existing state
    //
    set = old_state;
    sigaddset(&set, signal_to_block);

    //block that signal also
    //
    sigprocmask(SIG_BLOCK, &set, NULL);

    //... deal with old_state if required ...
}

    Wenn Sie möchten, um den vorherigen Zustand wiederherzustellen später, stellen Sie sicher, speichern Sie die old_state irgendwo sicher. Wenn Sie rufen Sie die Funktion mehrfach auf, müssen Sie entweder einen Stapel oder nur speichern Sie die ersten oder letzten old_state... oder vielleicht haben Sie eine Funktion, die entfernt ein bestimmtes signal blockiert.

    Für weitere Informationen Lesen Sie die Manpage.

    InformationsquelleAutor der Antwort Alexis Wilke

Schreibe einen Kommentar