Allgemeine Frage zu SIGPIPE

03/02/2016 - 09:48 von Edzard Egberts | Report spam
Ich habe ein Programm, das über Sockets TCP/IP-Verbindungen unterhàlt.
Wenn ich das Programm im Debugger laufen lasse, erhalte ich gelegentlich
(z.B. Herumbasteln an der Firewall) folgende Meldung:

Program received signal SIGPIPE, Broken pipe.
0xb805df8e in send () from /lib/libpthread.so.0

Der Debugger stoppt dann und làuft mit "Continue" weiter, was mir sagt,
dass ich dieses Signal behandeln sollte, nàmlich mit signal(SIGPIPE,
SIG_IGN) abstellen. Im Release wird das Signal scheinbar per default
nicht bearbeitet? Ist das richtig, oder kann das im Release das Programm
beenden?

Ich habe dazu noch gelesen, dass man Signale nicht ignorieren, sondern
besser blocken sollte, das erscheint mir aber nicht so gut, weil die
dann im Zustand "pending" bleiben.

Eine Fehlerbehandlung habe ich auch noch durch die Socket-Meldungen,
SIGPIPE kommt zusàtzlich zum "Socket closed" mit Fehlernummer und wird
von mir nicht gebraucht.

Meine eigentliche Frage ist jetzt, wie das mit der Bearbeitung dieses
Signals ursprünglich gedacht war und ob es eine bessere Strategie gibt,
als das einfach zu ignorieren. Es kommt mir darauf an, dass das Programm
möglichst ungestört weiter làuft, da eine unterbrochene Verbindung an
anderer Stelle behandelt wird.
 

Lesen sie die antworten

#1 Rainer Weikusat
03/02/2016 - 16:22 | Warnen spam
Edzard Egberts writes:
Ich habe ein Programm, das über Sockets TCP/IP-Verbindungen unterhàlt.
Wenn ich das Programm im Debugger laufen lasse, erhalte ich gelegentlich
(z.B. Herumbasteln an der Firewall) folgende Meldung:

Program received signal SIGPIPE, Broken pipe.
0xb805df8e in send () from /lib/libpthread.so.0

Der Debugger stoppt dann und làuft mit "Continue" weiter, was mir sagt,
dass ich dieses Signal behandeln sollte, nàmlich mit signal(SIGPIPE,
SIG_IGN) abstellen. Im Release wird das Signal scheinbar per default
nicht bearbeitet? Ist das richtig, oder kann das im Release das Programm
beenden?



Falls es nicht anderweitig abgestellt wurde, ja.

Ich habe dazu noch gelesen, dass man Signale nicht ignorieren, sondern
besser blocken sollte, das erscheint mir aber nicht so gut, weil die
dann im Zustand "pending" bleiben.



Es ist auch Unsinn (Erklaerung folgt).

[...]

Meine eigentliche Frage ist jetzt, wie das mit der Bearbeitung dieses
Signals ursprünglich gedacht war und ob es eine bessere Strategie gibt,
als das einfach zu ignorieren.



Es war/ ist dafuer gedacht, dass man die Ausgabe beliebiger Programme in
einen 'dynamisch verbundenen stream', zB eine pipe oder TCP-Verbindung,
umleiten kann, ohne dass diese besondere Fehlerbehandlung fuer
"Verbindung ploetzlich zusammengebrochen" implementieren: Versucht ein
Programm in einer solchen Situation Daten zu schreiben, sendet der
Kernel ein SIGPIPE das es beendet. Falls ein Programm 'weiss', dass es
mit dieser Situation zu rechnen hat, kann es SIGPIPE auf SIG_IGN setzen
und sich stattdessen um den EPIPE Fehler kuemmern.

Ähnliche fragen