Provided by: manpages-de_2.14-1_all bug

BEZEICHNUNG

       signal - Überblick über Signale (Software-Interrupts)

BESCHREIBUNG

       Linux    unterstützt    sowohl    nach   POSIX   zuverlässige   Signale   (im   Folgenden:
       »Standard-Signale«) und POSIX-Echtzeit-Signale.

   Signalzuordnung (disposition)
       Jedes Signal hat eine aktuelle Zuordnung. Sie legt fest, wie  sich  der  Prozess  verhält,
       wenn er das Signal erhält.

       Die  Einträge in der »Aktion«-Spalte in den folgenden Tabellen legen die Standardzuordnung
       für jedes Signal fest:

       Term   Standardaktion ist der Abbruch des Prozesses.

       Ign    Standardaktion ist, das Signal zu ignorieren.

       Core   Die  Standardaktion  ist  der  Abbruch  des  Prozesses  und  das  Erstellen   eines
              Speicherauszugs (siehe core(5)).

       Stop   Die Standardaktion ist, den Prozess anzuhalten.

       Cont   Die Standardaktion ist, einen angehaltenen Prozess fortzusetzen.

       Ein  Prozess  kann  die  Zuordnung eines Signals mit Hilfe von sigaction(2) oder signal(2)
       ändern. (Letzteres ist schlechter portierbar bei  der  Realisierung  von  Signal-Handlern;
       siehe  signal(2)  für  Details.)  Mit  diesen  Systemaufrufen  kann  ein  Prozess eine der
       folgenden  Verhaltensweisen  bei  Erhalt  eines  Signals  festlegen:  die   Standardaktion
       ausführen,  das  Signal  ignorieren oder das Signal mit einem Signal-Handler abfangen. Ein
       Signal-Handler ist eine  vom  Programmierer  definierte  Funktion.  Sie  wird  automatisch
       aufgerufen,  wenn  das  Signal  eintrifft.  (Standardmäßig wird der Signal-Handler auf dem
       normalen Prozess-Stack aufgerufen. Man kann es einrichten, dass der  Signal-Handler  einen
       alternativen  Stack benutzt; vgl. sigaltstack(2) für eine Erörterung, wie das gemacht wird
       und wann es nützlich sein könnte).

       Die Signalzuordnung ist ein prozessbezogenes Attribut; in einer Multithread-Anwendung  ist
       die Zuordnung eines bestimmten Signales für alle Threads gleich.

       Ein  mittels  fork(2)  erstelltes  Kind  erbt  eine  Kopie  der  Signalzuordnungen  seines
       Elternprozesses. Während eines execve(2) werden die Zuordnungen von  verwalteten  Signalen
       auf  die  Vorgabe  zurückgesetzt;  die  Zuordnung  ignorierter  Signale werden unverändert
       gelassen.

   Ein Signal senden
       Die folgenden Systemaufrufe und Bibliotheksfunktionen ermöglichen dem aufrufenden Programm
       den Versand eines Signals:

       raise(3)        sendet dem aufrufenden Thread ein Signal

       kill(2)         sendet  ein  Signal  an  einen  bestimmten  Prozess, alle Mitglieder einer
                       bestimmten Prozessgruppe oder an alle Prozesse im System

       killpg(3)       sendet ein Signal an alle Mitglieder einer bestimmten Prozessgruppe

       pthread_kill(3) sendet ein Signal an einen bestimmten POSIX-Thread im gleichen Prozess wie
                       die aufrufende Routine

       tgkill(2)       Es  wird ein Signal an einen bestimmten Thread in einem bestimmten Prozess
                       gesendet. (Mit diesem Systemaufruf wird pthread_kill(3) realisiert.)

       sigqueue(3)     sendet ein  Echtzeit-Signal  und  zugehörige  Daten  an  einen  bestimmten
                       Prozess

   Warten auf ein abzufangendes Signal
       Die  folgenden  Systemaufrufe setzen die Ausführung des aufrufenden Prozesses oder Threads
       aus, bis ein Signal abgefangen wird  (oder  ein  nicht  abgefangenes  Signal  den  Prozess
       beendet):

       pause(2)        setzt die Ausführung aus, bis irgendein Signal abgefangen wird.

       sigsuspend(2)   ändert  zeitweise  die  Signalmaske (siehe unten) und setzt die Ausführung
                       aus, bis eines der nicht maskierten Signale abgefangen wird.

   Synchrone Signalannahme
       Anstatt ein Signal asynchron mit einem Signal-Handler abzufangen,  kann  ein  Signal  auch
       synchron  akzeptiert  werden.  Das  heißt,  die  Ausführung wird blockiert, bis das Signal
       gesendet wird. Dann liefert der Kernel Informationen über das Signal an  den  Aufrufenden.
       Es gibt zwei allgemeine Möglichkeiten, das zu tun:

       * sigwaitinfo(2), sigtimedwait(2) und sigwait(3) setzen die Ausführung aus, bis ein Signal
         gesendet wird, dass zu einer  festgelegen  Gruppe  von  Signalen  gehört.  Jeder  dieser
         Aufrufe gibt Informationen über das empfangene Signal zurück.

       * signalfd(2) gibt einen Dateideskriptor zurück. Mit ihm können Informationen über Signale
         gelesen werden, die dem Aufrufenden übermittelt werden. Jeder  Aufruf  von  read(2)  aus
         dieser  Datei  wird  blockiert,  bis eines der Signale aus der im Aufruf von signalfd(2)
         festgelegten  Menge  an  den  aufrufenden  Prozess  gesendet  wird.  Der   von   read(2)
         zurückgegebene Puffer enthält eine Struktur, die das Signal beschreibt.

   Signalmaske und anstehende Signale
       Ein  Signal  kann blockiert werden. Das bedeutet, dass es erst dann gesendet wird, nachdem
       es (später/verzögert) freigegeben wurde. Zwischen dem Zeitpunkt seiner Erzeugung  und  dem
       Zeitpunkt seines Versands wird es anstehend (pending) genannt.

       Jeder  Thread in einem Prozess hat eine unabhängige Signalauswahl-Maske (signal mask). Sie
       legt den Satz von Signalen fest, den der Thread derzeit blockiert. Ein Thread  kann  seine
       Signalauswahl-Maske   mit   pthread_sigmask(3)   manipulieren.   In  einer  traditionellen
       Single-Threaded-Anwendung kann sigprocmask(2) verwendet  werden,  um  die  Signalmaske  zu
       manipulieren.

       Ein  mittels  fork(2)  erstellter  Kindprozess erbt eine Kopie der Signalauswahl-Maske des
       Elternprozesses; sie bleibt über einen Aufruf von execve(2) erhalten.

       Ein Signal kann für einen Prozess als Ganzes oder  für  einen  bestimmten  Thread  erzeugt
       werden  (und  damit  anstehen).  Ein  Beispiel  für den ersten Fall ist die Verwendung von
       kill(2). Beispiele für den zweiten Fall sind bestimmte Signale wie SIGSEGV und SIGFPE, die
       als  Folge  der Ausführung einer bestimmten Maschinensprachen-Anweisung erzeugt werden und
       somit threadgerichtet sind sowie  Routinen  wie  pthread_kill(3),  die  Signale  an  einen
       bestimmten  Thread  senden.  Ein an einen Prozess gerichtetes Signal kann an jeden Thread,
       der derzeit das Signal nicht blockiert hat, gesendet  werden.  Wenn  mehr  als  einer  der
       Threads  das  Signal nicht blockiert hat, wählt der Kernel einen beliebigen Thread, an den
       das Signal gesendet wird.

       Ein Thread kann die aktuell für ihn anstehenden Signale mit sigpending(2)  ermitteln.  Das
       sind  einerseits  die für diesen Thread und andererseits die für seinen Prozess bestimmten
       Signale.

       Ein  mittels  fork(2)  erzeugter  Kindprozess  hat  anfangs  keine  anstehenden   Signale;
       anstehende Signale bleiben über execve(2) erhalten.

   Standard-Signale
       Linux  unterstützt  die  unten  aufgeführten  Standard-Signale. Mehrere Signalnummern sind
       architekturabhängig, was in der »Wert«-Spalte angegeben wird.  (Wo  drei  Werte  angegeben
       sind,  gilt der erste Wert in der Regel für Alpha und SPARC, der mittlere für x86, arm und
       die meisten anderen Architekturen und der letzte für MIPS.  (Die  Werte  für  PARISC  sind
       nicht dargestellt; lesen Sie die Linux-Kernelquellen für die Signalnummerierung auf dieser
       Architektur.) Ein  Bindestrich  (-)  bedeutet,  dass  ein  Signal  in  der  entsprechenden
       Architektur nicht vorhanden ist.

       Zuerst die im ursprünglichen POSIX.1-1990-Standard beschriebenen Signale:

       Signal      Wert     Aktion   Kommentar
       ────────────────────────────────────────────────────────────────────────────────────
       SIGHUP        1       Term    Verbindung am steuernden Terminal beendet
                                     (aufgehängt) oder der steuernde Prozess wurde beendet
       SIGINT        2       Term    Unterbrechung von der Tastatur
       SIGQUIT       3       Core    Abbruch von der Tastatur
       SIGILL        4       Core    ungültiger Befehl
       SIGABRT       6       Core    Abbruchsignal von abort(3)
       SIGFPE        8       Core    Fließkomma-Ausnahmefehler
       SIGKILL       9       Term    Kill-Signal
       SIGSEGV      11       Core    ungültige Speicherreferenz
       SIGPIPE      13       Term    defekte Pipe: Schreiben in eine Pipe ohne
                                     Leser; siehe pipe(7)
       SIGALRM      14       Term    Timersignal von alarm(2)
       SIGTERM      15       Term    Beendigungssignal (termination signal)
       SIGUSR1   30,10,16    Term    benutzerdefiniertes Signal 1
       SIGUSR2   31,12,17    Term    benutzerdefiniertes Signal 2
       SIGCHLD   20,17,18    Ign     Kindprozess angehalten oder beendet
       SIGCONT   19,18,25    Cont    fortsetzen, wenn angehalten
       SIGSTOP   17,19,23    Stop    Stop process
       SIGTSTP   18,20,24    Stop    Stop am Terminal eingegeben
       SIGTTIN   21,21,26    Stop    Terminal-Eingabe für Hintergrundprozess
       SIGTTOU   22,22,27    Stop    Terminal-Ausgabe für Hintergrundprozess

       Die Signale SIGKILL und SIGSTOP können nicht abgefangen, blockiert oder ignoriert werden.

       Als  nächstes  die  Signale,  die  nicht  in  POSIX.1-1990, aber in SUSv2 und POSIX.1-2001
       beschrieben sind.

       Signal        Wert     Aktion   Kommentar
       ─────────────────────────────────────────────────────────────────────────────
       SIGBUS      10,7,10     Core    Bus-Fehler (Speicherzugriffsfehler)
       SIGPOLL                 Term    abfragbares Ereignis (Sys V),
                                       Synonym für SIGIO
       SIGPROF     27,27,29    Term    Profiling-Timer abgelaufen
       SIGSYS      12,31,12    Core    Ungültiger Systemaufruf (SVr4);
                                       siehe auch seccomp(2)
       SIGTRAP        5        Core    Trace-/Haltepunkt-Trap
       SIGURG      16,23,21    Ign     dringende Gegebenheit an Socket (4.2BSD)
       SIGVTALRM   26,26,28    Term    virtueller Wecker (4.2BSD)
       SIGXCPU     24,24,30    Core    CPU-Zeitbegrenzung überschritten (4.2BSD)
                                       siehe setrlimit(2)
       SIGXFSZ     25,25,31    Core    Dateigrößenbegrenzung überschritten (4.2BSD)
                                       siehe setrlimit(2)

       Bis einschließlich Linux 2.2 war das Standardverhalten für SIGSYS,  SIGXCPU,  SIGXFSZ  und
       (auf   anderen   Architekturen  als  SPARC  und  MIPS)  SIGBUS  den  Prozess  (ohne  einen
       Speicherauszug zu erzeugen)  zu  beenden.  (Auf  einigen  anderen  UNIX-Systemen  ist  die
       Standardaktion  für SIGXCPUund SIGXFSZ, den Prozess ohne einen Speicherauszug zu beenden.)
       Linux 2.4 entspricht den Anforderungen von POSIX.1-2001 an diese Signale und  beendet  den
       Prozess mit einem Speicherauszug.

       Es folgen diverse weitere Signale.

       Signal        Wert     Aktion   Kommentar
       ─────────────────────────────────────────────────────────────────────────────────
       SIGIOT         6        Core    IOT-Trap; ein Synonym für SIGABRT
       SIGEMT       7,-,7      Term    Emulator-Trap
       SIGSTKFLT    -,16,-     Term    Stack-Fehler am Koprozessor (nicht verwendet)
       SIGIO       23,29,22    Term    E/A jetzt möglich (4.2BSD)
       SIGCLD       -,-,18     Ign     ein Synonym für SIGCHLD
       SIGPWR      29,30,19    Term    Stromausfall (System V)
       SIGINFO      29,-,-             ein Synonym für SIGPWR
       SIGLOST      -,-,-      Term    Dateisperre verloren/aufgehoben (nicht verwandt)

       SIGWINCH    28,28,20    Ign     Änderung der Fenstergröße (4.3BSD, Sun)
       SIGUNUSED    -,31,-     Core    synonym mit SIGSYS

       (Signal 29 ist SIGINFO / SIGPWR auf einer Alpha-Maschine, aber SIGLOST auf einer Sparc.)

       SIGEMT  ist  nicht  in  POSIX.1-2001  angegeben,  erscheint  aber trotzdem auf den meisten
       anderen UNIX-Systemen. Dort ist  die  Standardaktion  in  der  Regel  die  Beendigung  des
       Prozesses mit einem Speicherauszug.

       SIGPWR  (nicht  in  POSIX.1-2001 beschrieben) wird bei seinem Eintreten von diesen anderen
       UNIX-Systemen ignoriert.

       SIGIO (nicht in POSIX.1-2001 beschrieben) wird  standardmäßig  auf  verschiedenen  anderen
       UNIX-Systemen ignoriert.

       Wenn  das  Signal  definiert  ist,  ist auf den meisten Architekturen SIGUNUSED synonym zu
       SIGSYS. Seit Glibc 2.26 ist SIGUNUSED auf keiner Architektur mehr definiert.

   Echtzeit-Signale
       Beginnend mit Version 2.2 unterstützt Linux Echtzeit-Signale, wie sie ursprünglich in  den
       POSIX.1b-Echtzeit-Erweiterungen  definiert  wurden  (und  jetzt  in POSIX.1-2001 enthalten
       sind). Die Bereich der unterstützten Echtzeit-Signale wird von  den  Makros  SIGRTMIN  und
       SIGRTMAX definiert. POSIX.1-2001 verlangt, dass eine Umsetzung mindestens _POSIX_RTSIG_MAX
       (8) Echtzeit-Signale unterstützt.

       Der Linux-Kernel unterstützt eine Reihe von 33 verschiedenen Echtzeit-Signalen, nummeriert
       von 32 bis 64. Doch die Glibc-Umsetzung der POSIX-Threads verwendet intern zwei (für NPTL)
       oder drei (für LinuxThreads) Echtzeit-Signale (siehe pthreads (7)) und stellt den Wert von
       SIGRTMIN  passend  (auf  34  oder 35 ein). Da die Zahl der verfügbaren Echtzeit-Signale je
       nach  Glibc-Threading-Implementierung  variiert  und  diese  Variation  (entsprechend  dem
       verfügbaren  Kernel  und  der  Glibc)  zur  Laufzeit  auftreten  kann  und tatsächlich die
       verfügbaren Echtzeitsignale je nach UNIX-System variieren, sollten Programme  niemals  mit
       eincodierten    Zahlen    auf   Echtzeit-Signale   verweisen.   Stattdessen   sollte   auf
       Echtzeit-Signale immer mit der Notation  SIGRTMIN+n  verwiesen  werden  und  zur  Laufzeit
       überprüft werden, ob (SIGRTMIN+n) SIGRTMAX nicht übersteigt.

       Im Gegensatz zu Standard-Signalen haben Echtzeit-Signale keine vordefinierten Bedeutungen:
       der gesamte Satz von  Echtzeit-Signalen  kann  für  anwendungsspezifische  Zwecke  genutzt
       werden.

       Die  Standardaktion  für  ein  nicht  abgefangenes  Echtzeit-Signal  ist  der  Abbruch des
       Prozesses.

       Echtzeit-Signale zeichnen sich durch folgende Merkmale aus:

       1.  Von Echtzeit-Signalen können mehrere Instanzen anstehen. Im Gegensatz dazu  wird  beim
           Versand   mehrerer  Instanzen  eines  Standard-Signals,  während  das  Signal  aktuell
           blockiert ist, nur eine Instanz weiter anstehen.

       2.  Wenn das Signal mit Hilfe von sigqueue(3) gesendet wird, kann mit ihm ein begleitender
           Wert  (entweder  eine  Ganzzahl  (Integer)  oder ein Zeiger) gesendet werden. Wenn der
           empfangende Prozess mittels des SA_SIGINFO-Schalters für  sigaction(2)  einen  Handler
           für   dieses  Signal  implementiert,  kann  dieser  Wert  aus  dem  si_value-Feld  der
           siginfo_t-Struktur (das zweite Argument des Handlers) bestimmt werden. Darüber  hinaus
           können  die  Felder si_uid und si_pid dieser Struktur verwendet werden, um die PID und
           reale Benutzerkennung des Prozesses zu erhalten, der das Signal erzeugt hat.

       3.  Echtzeit-Signale  werden  in  einer  garantierten  Reihenfolge   zugestellt.   Mehrere
           Echtzeit-Signale  des  gleichen  Typs werden in der Reihenfolge zugestellt, in der sie
           gesendet wurden. Wenn verschiedene Echtzeit-Signale an einen Prozess geschickt werden,
           wird  das  Signal  mit  der  niedrigsten Signalnummer zuerst zugestellt. (D.h. niedrig
           nummerierte Signale haben höchste Priorität.) Im Gegensatz dazu  ist  die  Reihenfolge
           der   Zustellung   mehrerer  für  einen  Prozess  anstehender  Standard-Signale  nicht
           festgelegt.

       Wenn sowohl Standard- als auch Echtzeit-Signale für einen Prozess  anstehen,  macht  POSIX
       keine  Angabe  dazu,  welche  Signale  zuerst zugestellt werden. Linux gibt wie auch viele
       andere Implementierungen den Standard-Signalen den Vorzug.

       Nach POSIX sollte eine Umsetzung mindestens _POSIX_SIGQUEUE_MAX (32)  Echtzeit-Signale  in
       der  Warteschlange  eines  Prozesses  ermöglichen.  Allerdings  macht Linux das anders. Im
       Kernel bis einschließlich 2.6.7 legt Linux eine  systemweite  Obergrenze  für  die  Anzahl
       wartender  Echtzeit-Signale  für alle Prozesse fest. Diese Grenze kann eingesehen und (mit
       entsprechenden Rechten) durch die Datei /proc/sys/kernel/rtsig-max  geändert  werden.  Aus
       der  verwandten  Datei  /proc/sys/kernel/rtsig-nr  kann die Anzahl der aktuell anstehenden
       Signale ermittelt werden. In Linux  2.6.8  wurden  diese  /proc-Schnittstellen  durch  die
       Ressource  RLIMIT_SIGPENDING,  die  einen  benutzerspezifischen  Grenzwert  für anstehende
       Signale in der Warteschlange festlegt, ersetzt (siehe setrlimit(2)).

       Die Ergänzung um Echtzeitsignale erforderte  die  Verbreiterung  der  Signalmengenstruktur
       (sigset_t)  von  32  auf  64  Bit. Konsequenterweise wurden viele Systemaufrufe durch neue
       Systemaufrufe abgelöst, die die größeren Signalmengen unterstützten. Die alten  und  neuen
       Systemaufrufe sind wie folgt:

       Linux 2.0 und älter   Linux 2.2 und neuer
       sigaction(2)          rt_sigaction(2)
       sigpending(2)         rt_sigpending(2)
       sigprocmask(2)        rt_sigprocmask(2)
       sigreturn(2)          rt_sigreturn(2)
       sigsuspend(2)         rt_sigsuspend(2)
       sigtimedwait(2)       rt_sigtimedwait(2)

   Unterbrechung von Systemaufrufen und Bibliotheksfunktionen durch Signal-Handler
       Wenn    ein    Signal-Handler    aufgerufen    wird,   während   ein   Systemaufruf   oder
       Bibliotheksfunktionsaufruf blockiert ist, wird entweder:

       * nach Abschluss des Signal-Handlers der Aufruf neu gestartet oder

       * der Aufruf schlägt mit dem Fehler EINTR fehl.

       Welche dieser beiden Verhaltensweisen  eintritt,  hängt  von  der  Schnittstelle  und  der
       Verwendung  oder  Nichtverwendung  des  Schalters  SA_RESTART ab (siehe sigaction(2)). Die
       Einzelheiten  unterscheiden  sich  zwischen  UNIX-Systemen.  Im   Folgenden   werden   die
       Linux-Spezifika erörtert.

       Wenn  ein  blockierter  Aufruf einer der folgenden Schnittstellen von einem Signal-Handler
       unterbrochen wird, wird der  Aufruf  nach  der  Rückkehr  aus  dem  Signal-Handler  erneut
       gestartet,  wenn  der Schalter SA_RESTART verwendet wurde; anderenfalls schlägt der Aufruf
       mit dem Fehler EINTR fehl:

       * Aufrufe von read(2), readv(2), write(2), writev(2) und ioctl(2) für  »langsame«  Geräte.
         Bei »langsamen« Geräten kann ein E-/A-Aufruf für eine unbestimmte Zeit zu einer Blockade
         führen.  Zu  ihnen  gehören  beispielsweise  Terminals,  Pipes  und  Sockets.  Hat   ein
         E-/A-Aufruf  für  ein  langsames  Gerät  schon  Daten  übertragen  und  wird durch einen
         Signal-Handler unterbrochen, wird der  Aufruf  mit  einem  Erfolgs-Status  abgeschlossen
         (normalerweise  ist  das  die Zahl übertragener Bytes). Beachten Sie, dass eine (lokale)
         Festplatte  nach  dieser  Definition  kein  langsames  Gerät   ist.   E/A-Aktionen   auf
         Fesplattengeräten werden durch Signale nicht unterbrochen.

       * open(2), wenn er blockieren kann (z. B. beim Öffnen eines FIFOs; siehe fifo(7)).

       * wait(2), wait3(2), wait4(2), waitid(2) und waitpid(2).

       * Socket-Schnittstellen:   accept(2),   connect(2),   recv(2),  recvfrom(2),  recvmmsg(2),
         recvmsg(2), send(2), sendto(2) und sendmsg(2), es sei denn, es wurde für den Socket eine
         Zeitbegrenzung (Timeout) festgelegt (siehe unten).

       * Dateisperrende  Schnittstellen:  flock(2) und die Aktionen F_SETLKW und F_OFD_SETLKW von
         fcntl(2).

       * POSIX-Schnittstellen für Nachrichten-Warteschlangen: mq_receive(3),  mq_timedreceive(3),
         mq_send(3), and mq_timedsend(3).

       * futex(2) FUTEX_WAIT (seit Linux 2.6.22; vorher immer Fehlschlag mit EINTR).

       * io_getevents(2)

       * pthread_mutex_lock(3), pthread_cond_wait(3) und verwandte APIs.

       * futex(2) FUTEX_WAIT_BITSET.

       * POSIX-Semaphor-Schnittstellen:  sem_wait(3)  und  sem_timedwait(3)  (seit  Linux 2.6.22;
         vorher immer Fehlschlag mit EINTR).

       * read(2) von einem inotify(7)-Dateideskriptor (seit Linux 3.8;  vorher  immer  Fehlschlag
         mit EINTR).

       Folgende  Schnittstellen  werden  nach  einer  Unterbrechung  durch  einen Signal-Handler,
       unabhängig von der Verwendung von SA_RESTART nie erneut gestartet; sie schlagen immer  mit
       dem Fehler EINTR fehl:

       * »Eingabe«-Socket-Schnittstellen,   wenn   für  den  Socket  mittels  setsockopt(2)  eine
         Zeitbegrenzung (Timeout, SO_RCVTIMEO) festgelegt wurde: accept(2), recv(2), recvfrom(2),
         recvmmsg(2) (auch mit einem von NULL verschiedenen Argument timeout) und recvmsg(2).

       * »Ausgabe«-Socket-Schnittstellen,   wenn   für  den  Socket  mittels  setsockopt(2)  eine
         Zeitbegrenzung (Timeout, SO_RCVTIMEO) festgelegt wurde: connect(2),  send(2),  sendto(2)
         und sendmsg(2).

       * Schnittstellen,   mit   denen   auf  Signale  gewartet  wird:  pause(2),  sigsuspend(2),
         sigtimedwait(2) und sigwaitinfo(2).

       * Schnittstellen, die Dateideskriptoren mehrfach  nutzen:  epoll_wait(2),  epoll_pwait(2),
         poll(2), ppoll(2), select(2) und pselect(2).

       * System-V-IPC-Schnittstellen: msgrcv(2), msgsnd(2), semop(2), and semtimedop(2).

       * Schlaf-Systemaufrufe: clock_nanosleep(2), nanosleep(2), and usleep(3).

       * io_getevents(2)

       Die  Funktion  sleep(3) wird ebenfalls niemals neu gestartet, wenn sie durch einen Handler
       unterbrochen wurde, wird aber erfolgreich verlassen: Der Rückgabewert ist  die  Zeit,  die
       noch geschlafen werden sollte.

   Unterbrechung von Systemaufrufen und Bibliotheksfunktionen durch Stop-Signale
       Auf  Linux  können  sogar  ohne  Signal-Handler  bestimmte sperrende Systemaufrufe mit dem
       Fehler EINTR fehlschlagen, nachdem der Prozess von einem der  Stop-Signale  gestoppt  wird
       und  dann  mittels  SIGCONT  wieder  fortgesetzt. Dieses Verhalten ist nicht durch POSIX.1
       sanktioniert und tritt nicht auf anderen Systemen auf.

       Die folgenden Linux-Schnittstellen zeigen dieses Verhalten:

       * »Eingabe«-Socket-Schnittstellen,  wenn  für  den  Socket  mittels   setsockopt(2)   eine
         Zeitbegrenzung (Timeout, SO_RCVTIMEO) festgelegt wurde: accept(2), recv(2), recvfrom(2),
         recvmmsg(2) (auch mit einem von NULL verschiedenen Argument timeout) und recvmsg(2).

       * »Ausgabe«-Socket-Schnittstellen,  wenn  für  den  Socket  mittels   setsockopt(2)   eine
         Zeitbegrenzung  (Timeout,  SO_RCVTIMEO) festgelegt wurde: connect(2), send(2), sendto(2)
         und sendmsg(2), falls eine Sendezeitüberschreitung (SO_SNDTIMEO) gesetzt wurde.

       * epoll_wait(2), epoll_pwait(2).

       * semop(2), semtimedop(2).

       * sigtimedwait(2), sigwaitinfo(2).

       * Linux 3.7 und älter: read(2) von einem inotify(7)-Dateideskriptor

       * Linux 2.6.21 und früher: futex(2) FUTEX_WAIT, sem_timedwait(3), sem_wait(3).

       * Linux 2.6.8 und früher: msgrcv(2), msgsnd(2).

       * Linux 2.4 und früher: nanosleep(2).

KONFORM ZU

       POSIX.1, mit den beschriebenen Ausnahmen

ANMERKUNGEN

       Für eine Diskussion asynchron-Signal-sicherer Funktionen, siehe signal-safety(7).

SIEHE AUCH

       kill(1),  getrlimit(2),  kill(2),  restart_syscall(2),  rt_sigqueueinfo(2),  setitimer(2),
       setrlimit(2),   sgetmask(2),   sigaction(2),   sigaltstack(2),   signal(2),   signalfd(2),
       sigpending(2),  sigprocmask(2),  sigreturn(2),  sigsuspend(2),  sigwaitinfo(2),  abort(3),
       bsd_signal(3),   killpg(3),   longjmp(3),   pthread_sigqueue(3),   raise(3),  sigqueue(3),
       sigset(3), sigsetops(3), sigvec(3),  sigwait(3),  strsignal(3),  sysv_signal(3),  core(5),
       proc(5), nptl(7), pthreads(7), sigevent(7)

KOLOPHON

       Diese  Seite  ist  Teil  der  Veröffentlichung  4.16  des  Projekts  Linux-man-pages. Eine
       Beschreibung des Projekts, Informationen, wie Fehler  gemeldet  werden  können  sowie  die
       aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.

ÜBERSETZUNG

       Die   deutsche   Übersetzung  dieser  Handbuchseite  wurde  von  Martin  Eberhard  Schauer
       <Martin.E.Schauer@gmx.de>, Dr. Tobias Quathamer <toddy@debian.org>  und  Helge  Kreutzmann
       <debian@helgefjell.de> erstellt.

       Diese  Übersetzung  ist  Freie  Dokumentation;  lesen  Sie  die GNU General Public License
       Version  3  oder  neuer  bezüglich  der  Copyright-Bedingungen.  Es  wird  KEINE   HAFTUNG
       übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
       Mail an <debian-l10n-german@lists.debian.org>.