.\" -*- coding: UTF-8 -*- '\" t .\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de) .\" and Copyright (c) 2002, 2006, 2020 by Michael Kerrisk .\" and Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk .\" .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" 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 "3. April 2023" "Linux man\-pages 6.05.01" .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 "Signalzuordnung (disposition)" Jedes Signal hat eine aktuelle \fIZuordnung\fP. Sie legt fest, wie sich der Prozess verhält, wenn er das Signal erhält. .PP Die Einträge in der »Aktion«\-Spalte in der folgenden Tabelle legen die Standardzuordnung für jedes Signal fest: .TP Term Standardaktion ist der Abbruch des Prozesses. .TP Ign Standardaktion ist, das Signal zu ignorieren. .TP Core Die Standardaktion ist der Abbruch des Prozesses und das Erstellen eines Speicherauszugs (siehe \fBcore\fP(5)). .TP Stop Die Standardaktion ist, den Prozess anzuhalten. .TP Cont Die Standardaktion ist, einen angehaltenen Prozess fortzusetzen. .PP Ein Prozess kann die Zuordnung 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 auswählen: 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. .PP Standardmäßig wird ein 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. .PP Die Signalzuordnung ist ein prozessbezogenes Attribut; in einer Multithread\-Anwendung ist die Zuordnung eines bestimmten Signales für alle Threads gleich. .PP Ein mittels \fBfork\fP(2) erstellter Kindprozess erbt eine Kopie der Signalzuordnungen seines Elternprozesses. Während eines \fBexecve\fP(2) werden die Zuordnungen von verwalteten Signalen auf die Vorgabe zurückgesetzt; die Zuordnung ignorierter Signale werden unverändert gelassen. .SS "Ein Signal senden" Die folgenden Systemaufrufe und Bibliotheksfunktionen ermöglichen dem aufrufenden Programm den Versand eines Signals: .TP \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 \fBpidfd_send_signal\fP(2) sendet ein Signal an einen Prozess, der durch einen PID\-Dateideskriptor identifiziert ist. .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 Threads aus, bis ein Signal abgefangen wird (oder ein nicht abgefangenes Signal den Prozess beendet): .TP \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 \[bu] 3 \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 \[bu] \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. .PP 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. .PP Ein mittels \fBfork\fP(2) erstellter Kindprozess erbt eine Kopie der Signalmaske des Elternprozeses; die Signalmaske wird über \fBexecve\fP(2) hinweg erhalten. .PP Ein Signal kann Prozess\-orientiert oder Thread\-orientiert sein. Ein Prozess\-orientiertes Signal ist eines, das auf einen Prozess als gesamtes zielt (und daher daran anhängig ist). Ein Signal kann Prozess\-orientiert sein, da es vom Kernel für einen Grund außer einer Hardware\-Ausnahmebehandlung erzeugt wurde oder da es mittels \fBkill\fP(2) oder \fBsigqueue\fP(3) gesandt wurde. Ein Thread\-orientiertes Signal ist eines, das auf einen bestimmten Thread abzielt. Ein Signal kann Thread\-orientiert sein, da es als Konsequenz einer Ausführung einer bestimmten Anweisung in Maschinensprache erstellt wurde, die eine Hardware\-Ausnahmebehandlung auslöste (z.B. \fBSIGSEGV\fP für einen ungültigen Speicherzugriff oder \fBSIGFPE\fP für einen mathematischen Fehler) oder da es mit Schnittstellen wie \fBtgkill\fP(2) oder \fBpthread_kill\fP(3) auf einen bestimmten Thread zielte. .PP .\" Joseph C. Sible notes: .\" On Linux, if the main thread has the signal unblocked, then the kernel .\" will always deliver the signal there, citing this kernel code .\" .\" Per this comment in kernel/signal.c since time immemorial: .\" .\" /* .\" * Now find a thread we can wake up to take the signal off the queue. .\" * .\" * If the main thread wants the signal, it gets first crack. .\" * Probably the least surprising to the average bear. .\" */ .\" .\" But this does not mean the signal will be delivered only in the .\" main thread, since if a handler is already executing in the main thread .\" (and thus the signal is blocked in that thread), then a further .\" might be delivered in a different thread. .\" Ein Prozess\-orientiertes Signal kann an jeden der Threads ausgeliefert werden, der derzeit keine Signale blockiert. Falls mehr als ein Thread Signale nicht blockiert, dann wählt der Kernel einen beliebigen Thread aus, an den er das Signal ausliefert. .PP Ein Thread kann die aktuell für ihn anstehenden Gruppe von Signale mit \fBsigpending\fP(2) ermitteln. Das sind einerseits die für diesen Thread und andererseits die für seinen Prozess bestimmten Signale. .PP .\" Ein mittels \fBfork\fP(2) erstellter Kindprozess hat anfänglich eine leere anhängende Signalgruppe; die anhängende Signalgruppe wird über \fBexecve\fP(2) hinweg erhalten. .SS "Ausführung eines Signal\-Handlers" Immer wenn es einen Übergang von der Kernelmodus\-Ausführung zu der Anwendungsraum\-Ausführung gibt (z.B bei der Rückkehr aus einem Systemaufruf oder Einplanung eines Threads auf einer CPU), prüft der Kernel, ob es ein anhängendes, nicht blockiertes Signal gibt, für das der Prozess einen Signal\-Handler etabliert hat. Falls es ein solches anhängendes Signal gibt, passieren die folgenden Schritte: .IP (1) 5 Der Kernel führt die notwendigen Vorbereitungsschritte zur Ausführung des Signal\-Handlers durch: .RS .IP (1.1) 7 Das Signal wird aus der Menge der anhängenden Signale entfernt. .IP (1.2) Falls der Signal\-Handler durch einen Aufruf von \fBsigaction\fP(2) installiert wurde, der den Schalter \fBSA_ONSTACK\fP festlegte, und der Thread über einen definierten alternativen Signal\-Stack verfügt (mittels \fBsigaltstack\fP(2)), dann wird der Stack installiert. .IP (1.3) Verschiedene Teile des Signal\-bezogenen Kontextes werden in ein besonderes Frame gespeichert, das auf dem Stack erstellt wird. Die gespeicherten Informationen beinhalten: .RS .IP \[bu] 3 das Programmzählregister (d.h. die Adresse der nächsten Anweisung in dem Hauptprogramm, die ausgeführt werden soll, wenn der Signal\-Handler zurückkehrt); .IP \[bu] architekturabhängige Registerzustände, die zur Wiederaufnahme des unterbrochenen Programms benötigt werden; .IP \[bu] die aktuelle Signal\-Maske des Threads; .IP \[bu] die alternativen Signal\-Stack\-Einstellungen des Threads. .RE .IP (Falls der Signal\-Handler mittels des Schalters \fBSA_SIGINFO\fP von \fBsigaction\fP(2) installiert wurde, dann kann auf die obigen Informationen über das Objekt \fIucontext_t\fP, auf das durch das dritte Argument des Signal\-Handlers gezeigt wird, zugegriffen werden.) .IP (1.4) Jedes bei der Registrierung des Handlers mit \fBsigprocmask\fP(2) in \fIact\->sa_mask\fP festgelegte Signal wird zu der Signal\-Maske des Threads hinzugefügt. Das auszuliefernde Signal wird auch zu der Signal\-Maske hinzugefügt, außer \fBSA_NODEFER\fP wurde bei der Registrierung des Handlers festgelegt. Diese Signale sind daher während der Ausführung des Handlers blockiert. .RE .IP (2) Der Kernel konstruiert ein Frame für den Signal\-Handler auf dem Stack. Der Kernel setzt den Programmzähler für den Thread, so dass er auf die erste Anweisung der Signal\-Handler\-Funktion zeigt, und konfiguriert die Rücksprungadresse für diese Funktion, so dass sie auf ein Stück Code im Anwendungsraum zeigt, das als Signaltrampolin bekannt ist (beschrieben in \fBsigreturn\fP(2)). .IP (3) Der Kernel übergibt die Steuerung zurück an den Anwendungsraum, wo mit der Ausführung beim Anfang der Signal\-Handler\-Funktion fortgefahren wird. .IP (4) Wenn der Signal\-Handler zurückkehrt, wird die Steuerung an den Signal\-Trampolin\-Code übergeben. .IP (5) Das Signaltrampolin ruft den Systemaufruf \fBsigreturn\fP(2) auf, der die Informationen auf dem in Schritt 1 erstellten Stack\-Frame verwendet, um den Thread in dem Zustand wiederherzustellen, in dem er vor dem Aufruf des Signal\-Handlers war. Die Signalmaske und die alternativen Signal\-Stack\-Einstellungen des Threads werden als Teil dieser Prozedur wiederhergestellt. Nach Abschluss des Aufrufs von \fBsigreturn\fP(2) übergibt der Kernel die Steuerung wieder an den Anwendungsraum zurück und der Thread fährt mit der Ausführung an dem Punkt fort, an dem er durch den Signal\-Handler unterbrochen wurde. .PP Beachten Sie, dass der abschließende Schritt nicht ausgeführt wird, falls der Signal\-Handler nicht zurückkehrt (z.B. weil die Steuerung mittels \fBsiglongjmp\fP(3) aus dem Handler herausverlegt wurde oder der Handler mittels \fBexecve\fP(2) ein neues Programm ausführt). In solchen Szenarien ist es insbesondere die Verantwortung des Programmierers, den Zustand der Signalmaske (mittels \fBsigprocmask\fP(2)) wiederherzustellen, falls gewünscht wird, die Blockierung der Signale aufzuheben, die beim Eintritt in den Signal\-Handler blockiert wurden. (Beachten Sie, dass \fBsiglongjmp\fP(3) die Signal\-Maske wiederherstellen könnte oder auch nicht, abhängig vom Wert \fIsavesigs\fP, der beim entsprechenden Aufruf von \fBsigsetjmp\fP(3) festgelegt wurde.) .PP .\" Vom Standpunkt des Kernels aus ist die Ausführung des Signal\-Handler\-Codes genau das gleiche wie die Ausführung jedes anderen Codes im Anwendungsraum. Dies bedeutet, dass der Kernel keinerlei besondere Zustandsinformationen aufzeichnet, die anzeigen, dass der Thread sich derzeit in der Ausführung eines Signal\-Handlers befindet. Alle notwendigen Zustandsinformationen werden in Anwendungsraum\-Registern und im Anwendungsraum\-Stack verwaltet. Die Tiefe, zu der verschachtelte Signal\-Handler aufgerufen werden können, wird daher durch den Anwendungsraum\-Stack begrenzt (und unterliegt daher dem Design der Software). .SS Standard\-Signale Linux untersützt die nachfolgend aufgeführten Standard\-Signale. Die zweite Spalte der Tabelle zeigt an, welcher Standard (falls vorhanden) das Signal festlegt: »P1990« zeigt an, dass das Signal in dem ursprünglichen Standard POSIX.1\-1990 beschrieben wurde; »P2001« zeigt an, dass das Signal in SUSv2 und POSIX.1\-2001 hinzugefügt wurde. .TS l c c l ____ lB c c l. Signal Standard Aktion Kommentar SIGABRT P1990 Core Abbruchsignal von \fBabort\fP(3) SIGALRM P1990 Term Timersignal von \fBalarm\fP(2) SIGBUS P2001 Core Bus\-Fehler (Speicherzugriffsfehler) SIGCHLD P1990 Ign Kindprozess angehalten oder beendet SIGCLD \- Ign ein Synonym für \fBSIGCHLD\fP SIGCONT P1990 Cont fortsetzen, wenn angehalten SIGEMT \- Term Emulator\-Ausnahmebehandlung SIGFPE P1990 Core Fließkomma\-Ausnahmefehler SIGHUP P1990 Term Verbindung am steuernden Terminal beendet (aufgehängt) oder der steuernde Prozess wurde beendet SIGILL P1990 Core ungültiger Befehl SIGINFO \- ein Synonym für \fBSIGPWR\fP SIGINT P1990 Term Unterbrechung von der Tastatur SIGIO \- Term E/A jetzt möglich (4.2BSD) SIGIOT \- Core IOT\-Ausnahmebehandlung; ein Synonym für \fBSIGABRT\fP SIGKILL P1990 Term Kill\-Signal SIGLOST \- Term Dateisperre verloren/aufgehoben (nicht verwandt) SIGPIPE P1990 Term defekte Pipe: Schreiben in eine Pipe ohne Leser; siehe \fBpipe\fP(7) SIGPOLL P2001 Term abfragbares Ereignis (Sys V) Synonym für \fBSIGIO\fP SIGPROF P2001 Term Profiling\-Timer abgelaufen SIGPWR \- Term Stromausfall (System V) SIGQUIT P1990 Core Abbruch von der Tastatur SIGSEGV P1990 Core ungültige Speicherreferenz SIGSTKFLT \- Term Stack\-Ausnahmebehandlung am Koprozessor (nicht verwendet) SIGSTOP P1990 Stop Stop process SIGTSTP P1990 Stop Stop am Terminal eingegeben SIGSYS P2001 Core Ungültiger Systemaufruf (SVr4); siehe auch \fBseccomp\fP(2) SIGTERM P1990 Term Beendigungssignal (termination signal) SIGTRAP P2001 Core Trace\-/Haltepunkt\-Ausnahmebehandlung SIGTTIN P1990 Stop Terminal\-Eingabe für Hintergrundprozess SIGTTOU P1990 Stop Terminal\-Ausgabe für Hintergrundprozess SIGUNUSED \- Core synonym mit \fBSIGSYS\fP SIGURG P2001 Ign dringende Gegebenheit an Socket (4.2BSD) SIGUSR1 P1990 Term benutzerdefiniertes Signal 1 SIGUSR2 P1990 Term benutzerdefiniertes Signal 2 SIGVTALRM P2001 Term virtueller Wecker (4.2BSD) SIGXCPU P2001 Core CPU\-Zeitbegrenzung überschritten (4.2BSD) siehe \fBsetrlimit\fP(2) SIGXFSZ P2001 Core Dateigrößenbegrenzung überschritten (4.2BSD) siehe \fBsetrlimit\fP(2) SIGWINCH \- Ign Änderung der Fenstergröße (4.3BSD, Sun) .TE .PP Die Signale \fBSIGKILL\fP und \fBSIGSTOP\fP können nicht abgefangen, blockiert oder ignoriert werden. .PP 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. .PP \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. .PP \fBSIGPWR\fP (nicht in POSIX.1\-2001 beschrieben) wird bei seinem Eintreten von diesen anderen UNIX\-Systemen ignoriert. .PP .\" \fBSIGIO\fP (nicht in POSIX.1\-2001 beschrieben) wird standardmäßig auf verschiedenen anderen UNIX\-Systemen ignoriert. .SS "Warteschlange und Auslieferungssemantik für Standard\-Signale" Falls für einen Prozess mehrere Standard\-Signale anhängig sind, ist die Reihenfolge, in der diese Signale ausgeliefert werden, nicht spezifiziert. .PP .\" Standard\-Signale kennen keine Warteschlange. Falls mehrere Instanzen eines Standard\-Signals erstellt werden, während dieses Signal blockiert ist, wird nur eine Instanz des Signals als anhängig markiert (und das Signal wird ausgeliefert, genau wenn die Blockade aufgehoben wird). Im Fall, bei dem ein Standard\-Signal bereits anhängig ist, wird die dem Signal zugehörige Struktur \fIsiginfo_t\fP (siehe \fBsigaction\fP(2)) nicht bei der Ankunft nachfolgender Instanzen des gleichen Signals überschrieben. Daher wird der Prozess die Informationen, die zu der ersten Instanz des Signals gehören, erhalten. .SS "Signalnummerierung für Standard\-Signale" Der numerische Wert für jedes Signal wird in der nachfolgenden Tabelle angegeben. Wie in der Tabelle gezeigt, haben viele Signale verschiedene numerische Werte auf verschiedenen Architekturen. Der erste numerische Wert in jeder Zeile zeigt die Signalnummer auf X86, ARM und den meisten anderen Architekturen; der zweite Wert ist für Alpha und SPARC; der dritte für MIPS und der letzte für PARISC. Ein Bindestrich (\-) zeigt an, dass ein Signal auf der entsprechenden Architektur nicht vorhanden ist. .TS l c c c c l l c c c c l ______ lB c c c c l. Signal x86/ARM Alpha/ MIPS PARISC Hinweise die meisten anderen SPARC SIGHUP \01 \01 \01 \01 SIGINT \02 \02 \02 \02 SIGQUIT \03 \03 \03 \03 SIGILL \04 \04 \04 \04 SIGTRAP \05 \05 \05 \05 SIGABRT \06 \06 \06 \06 SIGIOT \06 \06 \06 \06 SIGBUS \07 10 10 10 SIGEMT \- \07 \07 \- SIGFPE \08 \08 \08 \08 SIGKILL \09 \09 \09 \09 SIGUSR1 10 30 16 16 SIGSEGV 11 11 11 11 SIGUSR2 12 31 17 17 SIGPIPE 13 13 13 13 SIGALRM 14 14 14 14 SIGTERM 15 15 15 15 SIGSTKFLT 16 \- \- \07 SIGCHLD 17 20 18 18 SIGCLD \- \- 18 \- SIGCONT 18 19 25 26 SIGSTOP 19 17 23 24 SIGTSTP 20 18 24 25 SIGTTIN 21 21 26 27 SIGTTOU 22 22 27 28 SIGURG 23 16 21 29 SIGXCPU 24 24 30 12 SIGXFSZ 25 25 31 30 SIGVTALRM 26 26 28 20 SIGPROF 27 27 29 21 SIGWINCH 28 28 20 23 SIGIO 29 23 22 22 SIGPOLL identisch zu SIGIO SIGPWR 30 29/\- 19 19 SIGINFO \- 29/\- \- \- SIGLOST \- \-/29 \- \- SIGSYS 31 12 12 31 SIGUNUSED 31 \- \- 31 .TE .PP Beachten Sie Folgendes: .IP \[bu] 3 Wenn das Signal definiert ist, ist \fBSIGUNUSED\fP synonym zu \fBSIGSYS\fP. Seit Glibc 2.26 ist \fBSIGUNUSED\fP auf keiner Architektur mehr definiert. .IP \[bu] .\" Signal 29 ist \fBSIGINFO\fP / \fBSIGPWR\fP (synonym für den gleichen Wert) auf einer Alpha\-Maschine, aber \fBSIGLOST\fP auf einer SPARC. .SS Echtzeit\-Signale Beginnend mit Linux 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 Standard\-Signalen 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 \[bu] 3 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 \[bu] 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 PID und reale Benutzerkennung des Prozesses zu erhalten, der das Signal erzeugt hat. .IP \[bu] 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. Bis einschließlich Linux 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)). .PP 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 "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 \[bu] 3 nach Abschluss des Signal\-Handlers der Aufruf neu gestartet oder .IP \[bu] 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. .PP .\" 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 \[bu] 3 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, 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. .IP \[bu] \fBopen\fP(2), wenn er blockieren kann (z. B. beim Öffnen eines FIFOs; siehe \fBfifo\fP(7)). .IP \[bu] \fBwait\fP(2), \fBwait3\fP(2), \fBwait4\fP(2), \fBwaitid\fP(2) und \fBwaitpid\fP(2). .IP \[bu] .\" 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 Linux 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 \[bu] Dateisperrende Schnittstellen: \fBflock\fP(2) und die Aktionen \fBF_SETLKW\fP und \fBF_OFD_SETLKW\fP von \fBfcntl\fP(2). .IP \[bu] POSIX\-Schnittstellen für Nachrichten\-Warteschlangen: \fBmq_receive\fP(3), \fBmq_timedreceive\fP(3), \fBmq_send\fP(3), and \fBmq_timedsend\fP(3). .IP \[bu] .\" commit 72c1bbf308c75a136803d2d76d0e18258be14c7a \fBfutex\fP(2) \fBFUTEX_WAIT\fP (seit Linux 2.6.22; vorher immer Fehlschlag mit \fBEINTR\fP). .IP \[bu] \fBio_getevents\fP(2) .IP \[bu] \fBpthread_mutex_lock\fP(3), \fBpthread_cond_wait\fP(3) und verwandte APIs. .IP \[bu] \fBfutex\fP(2) \fBFUTEX_WAIT_BITSET\fP. .IP \[bu] .\" 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). .IP \[bu] .\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06 \fBread\fP(2) von einem \fBinotify\fP(7)\-Dateideskriptor (seit Linux 3.8; 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 \[bu] 3 »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 \[bu] .\" 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 \[bu] Schnittstellen, mit denen auf Signale gewartet wird: \fBpause\fP(2), \fBsigsuspend\fP(2), \fBsigtimedwait\fP(2) und \fBsigwaitinfo\fP(2). .IP \[bu] 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 \[bu] .\" 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 \[bu] Schlaf\-Systemaufrufe: \fBclock_nanosleep\fP(2), \fBnanosleep\fP(2), and \fBusleep\fP(3). .IP \[bu] \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. .PP .\" Unter bestimmten Umständen kann die Benachrichtigungsfunktionalität im Benutzerraum von \fBseccomp\fP(2) zum Neustart von Systemaufrufen führen, die andernfalls niemals durch \fBSA_RESTART\fP neugestartet würden; für Details siehe \fBseccomp_unotify\fP(2). .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 wird von POSIX.1 nicht gebiligt und tritt nicht auf anderen Systemen auf. .PP Die folgenden Linux\-Schnittstellen zeigen dieses Verhalten: .IP \[bu] 3 »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 \[bu] .\" 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 \[bu] \fBepoll_wait\fP(2), \fBepoll_pwait\fP(2). .IP \[bu] \fBsemop\fP(2), \fBsemtimedop\fP(2). .IP \[bu] \fBsigtimedwait\fP(2), \fBsigwaitinfo\fP(2). .IP \[bu] .\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06 Linux 3.7 und älter: \fBread\fP(2) von einem \fBinotify\fP(7)\-Dateideskriptor .IP \[bu] Linux 2.6.21 und früher: \fBfutex\fP(2) \fBFUTEX_WAIT\fP, \fBsem_timedwait\fP(3), \fBsem_wait\fP(3). .IP \[bu] Linux 2.6.8 und früher: \fBmsgrcv\fP(2), \fBmsgsnd\fP(2). .IP \[bu] Linux 2.4 und früher: \fBnanosleep\fP(2). .SH STANDARDS POSIX.1, mit den beschriebenen Ausnahmen .SH ANMERKUNGEN Für eine Diskussion asynchron\-Signal\-sicherer Funktionen, siehe \fBsignal\-safety\fP(7). .PP Die Datei \fI/proc/\fPPID\fI/task/[TID]/status\fP enthält verschiedene Felder, die die Signale, die ein Thread blockiert (\fISigBlk\fP), abfängt (\fISigCgt\fP) oder ignoriert (\fISigIgn\fP) zeigt. (Die Gruppe der abgefangenen oder ignorierten Signale wird für alle Threads eines Prozesses identisch sein.) Andere Felder zeigen die Gruppe der anhängenden Signale, die für den Thread bestimmt sind (\fISigPnd\fP) sowie die Gruppe der anhängenden Signale, die für den Prozess als ganzes bestimmt sind (\fIShdPnd\fP). Die entsprechenden Felder in \fI/proc/\fPPID\fI/status\fP zeigen die Informationen für den Haupt\-Thread. Siehe \fBproc\fP(5) für weitere Details. .SH FEHLER Es gibt sechs Signale, die als Konsequenz aus einer Hardware\-Ausnahmebehandlung ausgeliefert werden können: \fBSIGBUS\fP, \fBSIGEMT\fP, \fBSIGFPE\fP, \fBSIGILL\fP, \fBSIGSEGV\fP und \fBSIGTRAP\fP. Welches dieser Signale für eine bestimmte Hardware\-Ausnahmebehandlung ausgeliefert wird, ist nicht dokumentiert und ergibt nicht immer Sinn. .PP Zum Beispiel kann ein ungültiger Speicherzugriff, der die Auslieferung von \fBSIGSEGV\fP auf einer CPU\-Architektur hervorruft, die Auslieferung von \fBSIGBUS\fP auf einer anderen Architektur (oder andersherum) hervorrufen. .PP Als weiteres Beispiel löst die Verwendung der X86\-\fIint\fP\-Anweisung mit einem verbotenen Argument (jeder Zahl außer 3 und 128) die Auslieferung von \fBSIGSEGV\fP aus, obwohl \fBSIGILL\fP mehr Sinn ergäbe, aufgrund der Art, wie die CPU die verbotene Operation an den Kernel berichtet. .SH "SIEHE AUCH" \fBkill\fP(1), \fBclone\fP(2), \fBgetrlimit\fP(2), \fBkill\fP(2), \fBpidfd_send_signal\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), \fBsigreturn\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), \fBswapcontext\fP(3), \fBsysv_signal\fP(3), \fBcore\fP(5), \fBproc\fP(5), \fBnptl\fP(7), \fBpthreads\fP(7), \fBsigevent\fP(7) .PP .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Eberhard Schauer , Dr. Tobias Quathamer und Helge Kreutzmann erstellt. .PP Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. .PP Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die .MT debian-l10n-german@lists.debian.org Mailingliste der Übersetzer .ME .