.\" -*- coding: UTF-8 -*- '\" t .\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de) .\" and Copyright (c) 2002, 2006 by Michael Kerrisk .\" and Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk .\" .\" .\" %%%LICENSE_START(VERBATIM) .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" %%%LICENSE_END .\" .\" Modified Sat Jul 24 17:34:08 1993 by Rik Faith (faith@cs.unc.edu) .\" Modified Sun Jan 7 01:41:27 1996 by Andries Brouwer (aeb@cwi.nl) .\" Modified Sun Apr 14 12:02:29 1996 by Andries Brouwer (aeb@cwi.nl) .\" Modified Sat Nov 13 16:28:23 1999 by Andries Brouwer (aeb@cwi.nl) .\" Modified 10 Apr 2002, by Michael Kerrisk .\" Modified 7 Jun 2002, by Michael Kerrisk .\" Added information on real-time signals .\" Modified 13 Jun 2002, by Michael Kerrisk .\" Noted that SIGSTKFLT is in fact unused .\" 2004-12-03, Modified mtk, added notes on RLIMIT_SIGPENDING .\" 2006-04-24, mtk, Added text on changing signal dispositions, .\" signal mask, and pending signals. .\" 2008-07-04, mtk: .\" Added section on system call restarting (SA_RESTART) .\" Added section on stop/cont signals interrupting syscalls. .\" 2008-10-05, mtk: various additions .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH SIGNAL 7 "8. Oktober 2016" Linux Linux\-Programmierhandbuch .SH BEZEICHNUNG signal \- Überblick über Signale (Software\-Interrupts) .SH BESCHREIBUNG Linux unterstützt sowohl nach POSIX zuverlässige Signale (im Folgenden: »Standard\-Signale«) und POSIX\-Echtzeit\-Signale. .SS "Signal\-Wirkungen (disposition)" Jedes Signal hat eine aktuelle \fIWirkung\fP. 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: .IP Term Standardaktion ist der Abbruch des Prozesses. .IP Ign Standardaktion ist, das Signal zu ignorieren. .IP Core Die Standardaktion ist der Abbruch des Prozesses und das Erstellen eines Speicherauszugs (siehe \fBcore\fP(5)). .IP Stop Die Standardaktion ist, den Prozess anzuhalten. .IP Cont Die Standardaktion ist, einen angehaltenen Prozess fortzusetzen. .PP Ein Prozess kann die Wirkung eines Signals mit Hilfe von \fBsigaction\fP(2) oder \fBsignal\fP(2) ändern. (Letzteres ist schlechter portierbar bei der Realisierung von Signal\-Handlern; siehe \fBsignal\fP(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 \fISignal\-Handler\fP 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. \fBsigaltstack\fP(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 \fBfork\fP(2) erzeugter Kindprozess reagiert auf ein Signal wie der Prozess, der ihn erzeugte. Während eines \fBexecve\fP(2) werden die Reaktionen auf behandelte Signale auf die Standardwerte zurückgesetzt, die Reaktion auf ignorierte Signale bleibt unverändert. .SS "Ein Signal senden" Die folgenden Systemaufrufe und Bibliotheksfunktionen ermöglichen dem aufrufenden Programm den Versand eines Signals: .TP 16 \fBraise\fP(3) sendet dem aufrufenden Thread ein Signal .TP \fBkill\fP(2) sendet ein Signal an einen bestimmten Prozess, alle Mitglieder einer bestimmten Prozessgruppe oder an alle Prozesse im System .TP \fBkillpg\fP(3) sendet ein Signal an alle Mitglieder einer bestimmten Prozessgruppe .TP \fBpthread_kill\fP(3) sendet ein Signal an einen bestimmten POSIX\-Thread im gleichen Prozess wie die aufrufende Routine .TP \fBtgkill\fP(2) Es wird ein Signal an einen bestimmten Thread in einem bestimmten Prozess gesendet. (Mit diesem Systemaufruf wird \fBpthread_kill\fP(3) realisiert.) .TP \fBsigqueue\fP(3) sendet ein Echtzeit\-Signal und zugehörige Daten an einen bestimmten Prozess .SS "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): .TP 16 \fBpause\fP(2) setzt die Ausführung aus, bis irgendein Signal abgefangen wird. .TP \fBsigsuspend\fP(2) ändert zeitweise die Signalmaske (siehe unten) und setzt die Ausführung aus, bis eines der nicht maskierten Signale abgefangen wird. .SS "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: .IP * 2 \fBsigwaitinfo\fP(2), \fBsigtimedwait\fP(2) und \fBsigwait\fP(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. .IP * \fBsignalfd\fP(2) gibt einen Dateideskriptor zurück. Mit ihm können Informationen über Signale gelesen werden, die dem Aufrufenden übermittelt werden. Jeder Aufruf von \fBread\fP(2) aus dieser Datei wird blockiert, bis eines der Signale aus der im Aufruf von \fBsignalfd\fP(2) festgelegten Menge an den aufrufenden Prozess gesendet wird. Der von \fBread\fP(2) zurückgegebene Puffer enthält eine Struktur, die das Signal beschreibt. .SS "Signalmaske und anstehende Signale" Ein Signal kann \fIblockiert\fP 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 \fIanstehend\fP (pending) genannt. Jeder Thread in einem Prozess hat eine unabhängige \fISignalauswahl\-Maske\fP (signal mask). Sie legt den Satz von Signalen fest, den der Thread derzeit blockiert. Ein Thread kann seine Signalauswahl\-Maske mit \fBpthread_sigmask\fP(3) manipulieren. In einer traditionellen Single\-Threaded\-Anwendung kann \fBsigprocmask\fP(2) verwendet werden, um die Signalmaske zu manipulieren. Ein mittels \fBfork\fP(2) erstellter Kindprozess erbt eine Kopie der Signalauswahl\-Maske des Elternprozesses; sie bleibt über einen Aufruf von \fBexecve\fP(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 \fBkill\fP(2). Beispiele für den zweiten Fall sind bestimmte Signale wie \fBSIGSEGV\fP und \fBSIGFPE\fP, die als Folge der Ausführung einer bestimmten Maschinensprachen\-Anweisung erzeugt werden und somit threadgerichtet sind sowie Routinen wie \fBpthread_kill\fP(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 \fBsigpending\fP(2) ermitteln. Das sind einerseits die für diesen Thread und andererseits die für seinen Prozess bestimmten Signale. Ein mittels \fBfork\fP(2) erzeugter Kindprozess hat anfangs keine anstehenden Signale; anstehende Signale bleiben über \fBexecve\fP(2) erhalten. .SS 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 \fInicht\fP 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: .TS l c c l ____ lB c c l. Signal Wert Aktion Kommentar SIGHUP \01 Term Verbindung am steuernden Terminal beendet (aufgehängt) oder der steuernde Prozess wurde beendet SIGINT \02 Term Unterbrechung von der Tastatur SIGQUIT \03 Core Abbruch von der Tastatur SIGILL \04 Core ungültiger Befehl SIGABRT \06 Core Abbruchsignal von \fBabort\fP(3) SIGFPE \08 Core Fließkomma\-Ausnahmefehler SIGKILL \09 Term Kill\-Signal SIGSEGV 11 Core ungültige Speicherreferenz SIGPIPE 13 Term defekte Pipe: Schreiben in eine Pipeline ohne Leser SIGALRM 14 Term Zeitsignal von \fBalarm\fP(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 .TE Die Signale \fBSIGKILL\fP und \fBSIGSTOP\fP 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. .TS l c c l ____ lB c c l. Signal Wert Aktion Kommentar SIGBUS 10,7,10 Core Bus\-Fehler (Speicherzugriffsfehler) SIGPOLL Term abfragbares Ereignis (Sys V), Synonym für \fBSIGIO\fP 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ößenbegrenzung überschritten (4.2BSD) .TE Bis einschließlich Linux 2.2 war das Standardverhalten für \fBSIGSYS\fP, \fBSIGXCPU\fP, \fBSIGXFSZ\fP und (auf anderen Architekturen als SPARC und MIPS) \fBSIGBUS\fP den Prozess (ohne einen Speicherauszug zu erzeugen) zu beenden. (Auf einigen anderen UNIX\-Systemen ist die Standardaktion für \fBSIGXCPU\fPund \fBSIGXFSZ\fP, 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. .TS l c c l ____ lB c c l. Signal Wert Aktion Kommentar SIGIOT 6 Core IOT\-Trap; ein Synonym für \fBSIGABRT\fP 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 \fBSIGCHLD\fP SIGPWR 29,30,19 Term Stromausfall (System V) SIGINFO 29,\-,\- ein Synonym für \fBSIGPWR\fP SIGLOST \-,\-,\- Term Dateisperre verloren/aufgehoben (nicht verwandt) SIGWINCH 28,28,20 Ign Änderung der Fenstergröße (4.3BSD, Sun) SIGUNUSED \-,31,\- Core synonym mit \fBSIGSYS\fP .TE (Signal 29 ist \fBSIGINFO\fP / \fBSIGPWR\fP auf einer Alpha\-Maschine, aber \fBSIGLOST\fP auf einer Sparc.) \fBSIGEMT\fP 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. \fBSIGPWR\fP (nicht in POSIX.1\-2001 beschrieben) wird bei seinem Eintreten von diesen anderen UNIX\-Systemen ignoriert. \fBSIGIO\fP (nicht in POSIX.1\-2001 beschrieben) wird standardmäßig auf verschiedenen anderen UNIX\-Systemen ignoriert. .\" parisc is the only exception: SIGSYS is 12, SIGUNUSED is 31 Wenn das Signal definiert ist, ist auf den meisten Architekturen \fBSIGUNUSED\fP synonym zu \fBSIGSYS\fP. .SS 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 \fBSIGRTMIN\fP und \fBSIGRTMAX\fP definiert. POSIX.1\-2001 verlangt, dass eine Umsetzung mindestens \fB_POSIX_RTSIG_MAX\fP (8) Echtzeit\-Signale unterstützt. .PP 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 \fBpthreads\fP (7)) und stellt den Wert von \fBSIGRTMIN\fP 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 \fIniemals mit eincodierten Zahlen auf Echtzeit\-Signale verweisen\fP. Stattdessen sollte auf Echtzeit\-Signale immer mit der Notation \fBSIGRTMIN\fP+n verwiesen werden und zur Laufzeit überprüft werden, ob (\fBSIGRTMIN\fP+n) \fBSIGRTMAX\fP nicht übersteigt. .PP Im Gegensatz zu Standardsignalen haben Echtzeit\-Signale keine vordefinierten Bedeutungen: der gesamte Satz von Echtzeit\-Signalen kann für anwendungsspezifische Zwecke genutzt werden. .PP Die Standardaktion für ein nicht abgefangenes Echtzeit\-Signal ist der Abbruch des Prozesses. .PP Echtzeit\-Signale zeichnen sich durch folgende Merkmale aus: .IP 1. 4 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. .IP 2. 4 Wenn das Signal mit Hilfe von \fBsigqueue\fP(3) gesendet wird, kann mit ihm ein begleitender Wert (entweder eine Ganzzahl (Integer) oder ein Zeiger) gesendet werden. Wenn der empfangende Prozess mittels des \fBSA_SIGINFO\fP\-Schalters für \fBsigaction\fP(2) einen Handler für dieses Signal implementiert, kann dieser Wert aus dem \fIsi_value\fP\-Feld der \fIsiginfo_t\fP\-Struktur (das zweite Argument des Handlers) bestimmt werden. Darüber hinaus können die Felder \fIsi_uid\fP und \fIsi_pid\fP dieser Struktur verwendet werden, um die Prozess\-ID und reale Benutzer\-ID des Prozesses zu erhalten, der das Signal erzeugt hat. .IP 3. 4 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. .PP 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. .PP Nach POSIX sollte eine Umsetzung mindestens \fB_POSIX_SIGQUEUE_MAX\fP (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 \fI/proc/sys/kernel/rtsig\-max\fP geändert werden. Aus der verwandten Datei \fI/proc/sys/kernel/rtsig\-nr\fP kann die Anzahl der aktuell anstehenden Signale ermittelt werden. In Linux 2.6.8 wurden diese \fI/proc\fP\-Schnittstellen durch die Ressource \fBRLIMIT_SIGPENDING\fP, die einen benutzerspezifischen Grenzwert für anstehende Signale in der Warteschlange festlegt, ersetzt (siehe \fBsetrlimit\fP(2)). Die Ergänzung um Echtzeitsignale erforderte die Verbreiterung der Signalmengenstruktur (\fIsigset_t\fP) 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: .TS lb lb l l. Linux 2.0 und älter Linux 2.2 und neuer \fBsigaction\fP(2) \fBrt_sigaction\fP(2) \fBsigpending\fP(2) \fBrt_sigpending\fP(2) \fBsigprocmask\fP(2) \fBrt_sigprocmask\fP(2) \fBsigreturn\fP(2) \fBrt_sigreturn\fP(2) \fBsigsuspend\fP(2) \fBrt_sigsuspend\fP(2) \fBsigtimedwait\fP(2) \fBrt_sigtimedwait\fP(2) .TE .\" .SS "Asynchrone, signalsichere Funktionen" .PP 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«. Falls ein Signal die Ausführung einer unsicheren Funktion unterbricht, und \fIhandler\fP entweder eine unsichere Funktion aufruft oder \fIhandler\fP sich mit einem Aufruf an \fBlongjmp\fP() oder \fBsiglongjmp\fP() beendet und das Programm nachfolgend eine unsichere Funktion aufruft, dann 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: .in +4 .nf _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() .fi .in .PP POSIX.1\-2008 entfernt fpathconf(), pathconf() und sysconf() aus der obigen Liste und fügt die folgenden Funktionen hinzu: .PP .in +4n .nf execl() execv() faccessat() fchmodat() fchownat() fexecve() fstatat() futimens() linkat() mkdirat() mkfifoat() mknod() mknodat() openat() readlinkat() renameat() symlinkat() unlinkat() utimensat() utimes() .fi .in .PP POSIX.1\-2008 Technical Corrigendum 1 (2013) fügt die folgenden Funktionen hinzu: .PP .in +4n .nf fchdir() pthread_kill() pthread_self() pthread_sigmask() .fi .in .\" FIXME POSIX.1-2008 TC 2 looks set to add many more async-signal-safe .\" functions. Document these. .SS "Unterbrechung von Systemaufrufen und Bibliotheksfunktionen durch Signal\-Handler" Wenn ein Signal\-Handler aufgerufen wird, während ein Systemaufruf oder Bibliotheksfunktionsaufruf blockiert ist, wird entweder: .IP * 2 nach Abschluss des Signal\-Handlers der Aufruf neu gestartet oder .IP * der Aufruf schlägt mit dem Fehler \fBEINTR\fP fehl. .PP Welche dieser beiden Verhaltensweisen eintritt, hängt von der Schnittstelle und der Verwendung oder Nichtverwendung des Schalters \fBSA_RESTART\fP ab (siehe \fBsigaction\fP(2)). Die Einzelheiten unterscheiden sich zwischen UNIX\-Systemen. Im Folgenden werden die Linux\-Spezifika erörtert. .\" The following system calls use ERESTARTSYS, .\" so that they are restartable 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 \fBSA_RESTART\fP verwendet wurde; anderenfalls schlägt der Aufruf mit dem Fehler \fBEINTR\fP fehl: .IP * 2 Aufrufe von \fBread\fP(2), \fBreadv\fP(2), \fBwrite\fP(2), \fBwritev\fP(2) und \fBioctl\fP(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. 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. .IP * \fBopen\fP(2), wenn er blockieren kann (z. B. beim Öffnen eines FIFOs; siehe \fBfifo\fP(7)). .IP * \fBwait\fP(2), \fBwait3\fP(2), \fBwait4\fP(2), \fBwaitid\fP(2) und \fBwaitpid\fP(2). .IP * .\" If a timeout (setsockopt()) is in effect on the socket, then these .\" system calls switch to using EINTR. Consequently, they and are not .\" automatically restarted, and they show the stop/cont behavior .\" described below. (Verified from 2.6.26 source, and by experiment; mtk) .\" FIXME What about sendmmsg()? Socket\-Schnittstellen: \fBaccept\fP(2), \fBconnect\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2), \fBrecvmsg\fP(2), \fBsend\fP(2), \fBsendto\fP(2) und \fBsendmsg\fP(2), es sei denn, es wurde für den Socket eine Zeitbegrenzung (Timeout) festgelegt (siehe unten). .IP * Dateisperrende Schnittstellen: \fBflock\fP(2) und die Aktionen \fBF_SETLKW\fP und \fBF_OFD_SETLKW\fP von \fBfcntl\fP(2). .IP * POSIX\-Schnittstellen für Nachrichten\-Warteschlangen: \fBmq_receive\fP(3), \fBmq_timedreceive\fP(3), \fBmq_send\fP(3), and \fBmq_timedsend\fP(3). .IP * .\" commit 72c1bbf308c75a136803d2d76d0e18258be14c7a \fBfutex\fP(2) \fBFUTEX_WAIT\fP (seit Linux 2.6.22; vorher immer Fehlschlag mit \fBEINTR\fP). .IP * \fBio_getevents\fP(2) .IP * \fBpthread_mutex_lock\fP(3), \fBpthread_cond_wait\fP(3) und verwandte APIs. .IP * \fBfutex\fP(2) \fBFUTEX_WAIT_BITSET\fP. .IP * .\" as a consequence of the 2.6.22 changes in the futex() implementation POSIX\-Semaphor\-Schnittstellen: \fBsem_wait\fP(3) und \fBsem_timedwait\fP(3) (seit Linux 2.6.22; vorher immer Fehlschlag mit \fBEINTR\fP). .PP .\" These are the system calls that give EINTR or ERESTARTNOHAND .\" on interruption by a signal handler. Folgende Schnittstellen werden nach einer Unterbrechung durch einen Signal\-Handler, unabhängig von der Verwendung von \fBSA_RESTART\fP nie erneut gestartet; sie schlagen immer mit dem Fehler \fBEINTR\fP fehl: .IP * 2 »Eingabe«\-Socket\-Schnittstellen, wenn für den Socket mittels \fBsetsockopt\fP(2) eine Zeitbegrenzung (Timeout, \fBSO_RCVTIMEO\fP) festgelegt wurde: \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2) (auch mit einem von NULL verschiedenen Argument \fItimeout\fP) und \fBrecvmsg\fP(2). .IP * .\" FIXME What about sendmmsg()? »Ausgabe«\-Socket\-Schnittstellen, wenn für den Socket mittels \fBsetsockopt\fP(2) eine Zeitbegrenzung (Timeout, \fBSO_RCVTIMEO\fP) festgelegt wurde: \fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2) und \fBsendmsg\fP(2). .IP * Schnittstellen, mit denen auf Signale gewartet wird: \fBpause\fP(2), \fBsigsuspend\fP(2), \fBsigtimedwait\fP(2) und \fBsigwaitinfo\fP(2). .IP * Schnittstellen, die Dateideskriptoren mehrfach nutzen: \fBepoll_wait\fP(2), \fBepoll_pwait\fP(2), \fBpoll\fP(2), \fBppoll\fP(2), \fBselect\fP(2) und \fBpselect\fP(2). .IP * .\" On some other systems, SA_RESTART does restart these system calls System\-V\-IPC\-Schnittstellen: \fBmsgrcv\fP(2), \fBmsgsnd\fP(2), \fBsemop\fP(2), and \fBsemtimedop\fP(2). .IP * Schlaf\-Systemaufrufe: \fBclock_nanosleep\fP(2), \fBnanosleep\fP(2), and \fBusleep\fP(3). .IP * \fBread\fP(2) von einem \fBinotify\fP(7)\-Dateideskriptor .IP * \fBio_getevents\fP(2) .PP Die Funktion \fBsleep\fP(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. .SS "Unterbrechung von Systemaufrufen und Bibliotheksfunktionen durch Stop\-Signale" Auf Linux können sogar ohne Signal\-Handler bestimmte sperrende Systemaufrufe mit dem Fehler \fBEINTR\fP fehlschlagen, nachdem der Prozess von einem der Stop\-Signale gestoppt wird und dann mittels \fBSIGCONT\fP wieder fortgesetzt. Dieses Verhalten ist nicht durch POSIX.1 sanktioniert und tritt nicht auf anderen Systemen auf. Die folgenden Linux\-Schnittstellen zeigen dieses Verhalten: .IP * 2 »Eingabe«\-Socket\-Schnittstellen, wenn für den Socket mittels \fBsetsockopt\fP(2) eine Zeitbegrenzung (Timeout, \fBSO_RCVTIMEO\fP) festgelegt wurde: \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2) (auch mit einem von NULL verschiedenen Argument \fItimeout\fP) und \fBrecvmsg\fP(2). .IP * .\" FIXME What about sendmmsg()? »Ausgabe«\-Socket\-Schnittstellen, wenn für den Socket mittels \fBsetsockopt\fP(2) eine Zeitbegrenzung (Timeout, \fBSO_RCVTIMEO\fP) festgelegt wurde: \fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2) und \fBsendmsg\fP(2), falls eine Sendezeitüberschreitung (\fBSO_SNDTIMEO\fP) gesetzt wurde. .IP * 2 \fBepoll_wait\fP(2), \fBepoll_pwait\fP(2). .IP * \fBsemop\fP(2), \fBsemtimedop\fP(2). .IP * \fBsigtimedwait\fP(2), \fBsigwaitinfo\fP(2). .IP * \fBread\fP(2) von einem \fBinotify\fP(7)\-Dateideskriptor .IP * Linux 2.6.21 und früher: \fBfutex\fP(2) \fBFUTEX_WAIT\fP, \fBsem_timedwait\fP(3), \fBsem_wait\fP(3). .IP * Linux 2.6.8 und früher: \fBmsgrcv\fP(2), \fBmsgsnd\fP(2). .IP * Linux 2.4 und früher: \fBnanosleep\fP(2). .SH "KONFORM ZU" .\" It must be a *very* long time since this was true: .\" .SH BUGS .\" .B SIGIO .\" and .\" .B SIGLOST .\" have the same value. .\" The latter is commented out in the kernel source, but .\" the build process of some software still thinks that .\" signal 29 is .\" .BR SIGLOST . POSIX.1, mit den beschriebenen Ausnahmen .SH "SIEHE AUCH" \fBkill\fP(1), \fBgetrlimit\fP(2), \fBkill\fP(2), \fBrestart_syscall\fP(2), \fBrt_sigqueueinfo\fP(2), \fBsetitimer\fP(2), \fBsetrlimit\fP(2), \fBsgetmask\fP(2), \fBsigaction\fP(2), \fBsigaltstack\fP(2), \fBsignal\fP(2), \fBsignalfd\fP(2), \fBsigpending\fP(2), \fBsigprocmask\fP(2), \fBsigsuspend\fP(2), \fBsigwaitinfo\fP(2), \fBabort\fP(3), \fBbsd_signal\fP(3), \fBkillpg\fP(3), \fBlongjmp\fP(3), \fBpthread_sigqueue\fP(3), \fBraise\fP(3), \fBsigqueue\fP(3), \fBsigset\fP(3), \fBsigsetops\fP(3), \fBsigvec\fP(3), \fBsigwait\fP(3), \fBstrsignal\fP(3), \fBsysv_signal\fP(3), \fBcore\fP(5), \fBproc\fP(5), \fBnptl\fP(7), \fBpthreads\fP(7), \fBsigevent\fP(7) .SH KOLOPHON Diese Seite ist Teil der Veröffentlichung 4.09 des Projekts Linux\-\fIman\-pages\fP. 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/. .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Eberhard Schauer , Helge Kreutzmann und Dr. Tobias Quathamer 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 .