Provided by: manpages-de_1.4-1_all 
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.
Signal-Wirkungen (disposition)
Jedes Signal hat eine aktuelle Wirkung. 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 Standardwirkung
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 Wirkung 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 Reaktion auf das Signal ist ein Merkmal des ganzen Prozesses; in einer
Multithread-Anwendung wirkt das Signal auf alle Threads gleich.
Ein mittels fork(2) erzeugter Kindprozess reagiert auf ein Signal wie der Prozess, der ihn
erzeugte. Während eines execve(2) werden die Reaktionen auf behandelte Signale auf die
Standardwerte zurückgesetzt, die Reaktion auf ignorierte Signale bleibt unverändert.
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(2) 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 - 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 Anmerkung
────────────────────────────────────────────────────────────────────────
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 Abbruchsignal (kill)
SIGSEGV 11 Core ungültige Speicherreferenz
SIGPIPE 13 Term defekte Pipe: Schreiben in eine Pipeline
ohne Leser
SIGALRM 14 Term Zeitsignal 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 Prozess anhalten
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 Anmerkung
─────────────────────────────────────────────────────────────────────────
SIGBUS 10,7,10 Core Bus-Fehler (Speicherzugriffsfehler)
SIGPOLL Term abfragbares Ereignis (Sys V),
Synonym für SIGIO
SIGPROF 27,27,29 Term Profiling-Zeitgeber abgelaufen
SIGSYS 12,31,12 Core falsches Argument für Routine (SVr4)
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)
SIGXFSZ 25,25,31 Core Dateigrößen-Begrenzung überschritten
(4.2BSD)
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 Anmerkung
─────────────────────────────────────────────────────────────────────────────────
SIGIOT 6 Core IOT-Trap; ein Synonym für SIGABRT
SIGEMT 7,-,7 Term
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.
Echtzeit-Signale
Linux unterstützt 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 32 verschiedenen Echtzeit-Signalen, nummeriert
von 33 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 Standardsignalen 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
Prozess-ID und reale Benutzer-ID 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)).
Asynchrone, signalsichere Funktionen
Eine Signal-Handler-Funktion muss sehr sorgfältig programmiert werden, weil die
Verarbeitung an einer beliebigen Stelle unterbrochen werden kann. POSIX hat das Konzept
der »sicheren Funktion«. Wenn ein Signal die Ausführung einer unsicheren Funktion
unterbricht, und handler eine unsichere Funktion aufruft, ist das Verhalten des Programms
nicht definiert.
POSIX.1-2004 (auch als POSIX.1-2001 Technical Corrigendum 2 bekannt) fordert von einer
Implementierung, dass die folgenden Funktionen sicher sind, also unbedenklich in einem
Signal-Handler verwendet werden können:
_Exit()
_exit()
abort()
accept()
access()
aio_error()
aio_return()
aio_suspend()
alarm()
bind()
cfgetispeed()
cfgetospeed()
cfsetispeed()
cfsetospeed()
chdir()
chmod()
chown()
clock_gettime()
close()
connect()
creat()
dup()
dup2()
execle()
execve()
fchmod()
fchown()
fcntl()
fdatasync()
fork()
fpathconf()
fstat()
fsync()
ftruncate()
getegid()
geteuid()
getgid()
getgroups()
getpeername()
getpgrp()
getpid()
getppid()
getsockname()
getsockopt()
getuid()
kill()
link()
listen()
lseek()
lstat()
mkdir()
mkfifo()
open()
pathconf()
pause()
pipe()
poll()
posix_trace_event()
pselect()
raise()
read()
readlink()
recv()
recvfrom()
recvmsg()
rename()
rmdir()
select()
sem_post()
send()
sendmsg()
sendto()
setgid()
setpgid()
setsid()
setsockopt()
setuid()
shutdown()
sigaction()
sigaddset()
sigdelset()
sigemptyset()
sigfillset()
sigismember()
signal()
sigpause()
sigpending()
sigprocmask()
sigqueue()
sigset()
sigsuspend()
sleep()
sockatmark()
socket()
socketpair()
stat()
symlink()
sysconf()
tcdrain()
tcflow()
tcflush()
tcgetattr()
tcgetpgrp()
tcsendbreak()
tcsetattr()
tcsetpgrp()
time()
timer_getoverrun()
timer_gettime()
timer_settime()
times()
umask()
uname()
unlink()
utime()
wait()
waitpid()
write()
POSIX.1-2008 entfernt fpathconf(), pathconf() und sysconf() aus der obigen Liste und fügt
die folgenden Funktionen hinzu:
execl()
execv()
faccessat()
fchmodat()
fchownat()
fexecve()
fstatat()
futimens()
linkat()
mkdirat()
mkfifoat()
mknod()
mknodat()
openat()
readlinkat()
renameat()
symlinkat()
unlinkat()
utimensat()
utimes()
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, Pipelines und
Sockets. (Nach dieser Definition ist eine Festplatte kein langsames Gerät.) 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.)
* 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), 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 fcntl(2) F_SETLKW.
* 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).
* POSIX-Semaphor-Schnittstellen: sem_wait(3) und sem_timedwait(3) (seit Linux 2.6.22;
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:
* Socket-Schnittstellen, wenn für den Socket mittels setsockopt (2) eine
Zeitbegrenzung (Timeout) festgelegt wurde: accept(2), recv(2), recvfrom(2) und
recvmsg(2), wenn eine Empfangs-Zeitbegrenzung (SO_RCVTIMEO) gesetzt wurde;
connect(2), send(2), sendto(2), und sendmsg(2) sowie bei der Festsetzung von
Versand-Zeitbegrenzungen (SO_SNDTIMEO).
* 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).
* read(2) von einem inotify(7)-Dateideskriptor
* 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:
* Socket-Schnittstellen, wenn für den Socket mittels setsockopt (2) eine
Zeitbegrenzung (Timeout) festgelegt wurde: accept(2), recv(2), recvfrom(2) und
recvmsg(2), wenn eine Empfangs-Zeitbegrenzung (SO_RCVTIMEO) gesetzt wurde;
connect(2), send(2), sendto(2), und sendmsg(2) sowie bei der Festsetzung von
Versand-Zeitbegrenzungen (SO_SNDTIMEO).
* epoll_wait(2), epoll_pwait(2).
* semop(2), semtimedop(2).
* sigtimedwait(2), sigwaitinfo(2).
* 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
SIEHE AUCH
kill(1), getrlimit(2), kill(2), killpg(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), sigsuspend(2), sigwaitinfo(2), abort(3),
bsd_signal(3), longjmp(3), raise(3), pthread_sigqueue(3), sigqueue(3), sigset(3),
sigsetops(3), sigvec(3), sigwait(3), strsignal(3), sysv_signal(3), core(5), proc(5),
pthreads(7), sigevent(7)
KOLOPHON
This page is part of release 3.54 of the Linux man-pages project. A description of the
project, and information about reporting bugs, can be found at
http://www.kernel.org/doc/man-pages/.
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Eberhard Schauer
<Martin.E.Schauer@gmx.de> 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>.