it-swarm.com.de

Was bringt einen Unix-Prozess dazu, mit Broken Pipe zu sterben?

Hier sind einige Optionen, an die ich gedacht habe, nicht sicher, welche die richtige ist.

  1. Es ist ein E/A-Fehler beim Lesen aus der Pipe aufgetreten.
  2. Der Prozess, der an das andere Ende der Pipe geschrieben wurde, ist mit einem Fehler abgebrochen.
  3. Alle Prozesse, die in die Pipe schreiben konnten, haben sie geschlossen.
  4. Der Schreibpuffer der Pipe ist voll.
  5. Der Peer hat die andere Richtung des Duplexrohrs geschlossen.
  6. Das Schreiben ist fehlgeschlagen, da keine Prozesse aus der Pipe gelesen werden können.
  7. Ein Systemaufruf gab den EPIPE-Fehler zurück, und es war kein Fehlerhandler installiert.
31
siamii

Ein Prozess erhält ein SIGPIPE, wenn er versucht, in eine Pipe (mit oder ohne Namen) oder Socket vom Typ SOCK_STREAM zu schreiben, für die kein Reader mehr vorhanden ist.

Es ist allgemein erwünschtes Verhalten. Ein typisches Beispiel ist:

find . | head -n 1

Sie möchten nicht, dass find weiter ausgeführt wird, sobald head beendet wurde (und dann den einzigen Dateideskriptor geschlossen hat, der zum Lesen in dieser Pipe geöffnet ist).

Der Befehl yes basiert normalerweise auf diesem Signal, um beendet zu werden.

yes | some-command

Schreibt "y", bis ein Befehl beendet wird.

Beachten Sie, dass dies nicht nur beim Beenden von Befehlen geschieht, sondern auch, wenn alle Leser ihre Lesefunktion für die Pipe geschlossen haben. Im:

yes | ( sleep 1; exec <&-; ps -fC yes)
      1 2       1        0

Es wird 1 (die Unterschale), dann 2 (Unterschale + Schlaf), dann 1 (Unterschale) und dann 0 fd aus der Pipe gelesen, nachdem die Unterschale ihren Standard explizit geschlossen hat, und dann erhält yes ein SIGPIPE .

Oben verwenden die meisten Shells eine pipe(2), während ksh93 Eine socketpair(2) verwendet, aber das Verhalten ist in dieser Hinsicht dasselbe.

Wenn ein Prozess das SIGPIPE ignoriert, wird der Schreibsystemaufruf (im Allgemeinen write, könnte aber pwrite, send, splice... sein) mit a zurückgegeben EPIPE Fehler. Prozesse, die das kaputte Rohr manuell behandeln möchten, ignorieren SIGPIPE normalerweise und ergreifen Maßnahmen bei einem EPIPE-Fehler.

40

(6)

Das Schreiben ist fehlgeschlagen, da keine Prozesse aus der Pipe gelesen werden können.

Wenn Sie Deskriptoren und Fork nicht duplizieren, kann es zunächst nur einen Prozess geben: Im Allgemeinen hat eine Pipe einen Leser und einen Schreiber, und wenn einer von ihnen die Verbindung schließt, ist die Pipe nicht mehr vorhanden. Wenn Sie eine Named Pipe verwenden, können Sie mehrere Verbindungen (seriell) damit herstellen, aber jede repräsentiert eine neue Pipe in diesem Sinne. Eine "Pipe" zu einem Thread oder Prozess ist also gleichbedeutend mit einem Dateideskriptor.

Von man 7 pipe:

Wenn alle Dateideskriptoren, die sich auf das Leseende einer Pipe beziehen, geschlossen wurden, wird durch Schreiben (2) ein SIGPIPE-Signal für den aufrufenden Prozess generiert. Wenn der aufrufende Prozess dieses Signal ignoriert, schlägt das Schreiben (2) mit dem Fehler EPIPE fehl.

Eine "kaputte Pfeife" ist für den Schreiber das, was EOF für den Leser ist.

14
goldilocks

Ein Rohrbruch tritt auf, wenn der Lesevorgang vor dem Schreibvorgang beendet wird. Also würde ich mit (6) gehen

0
SidJ