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), 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 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:
- *
- »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).
- *
- 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:
- *
- »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).
- *
- 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).
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¶
Diese Seite ist Teil der Veröffentlichung 3.74 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
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>.