signal(7) Miscellaneous Information Manual signal(7) BEZEICHNUNG signal - Uberblick uber Signale (Software-Interrupts) BESCHREIBUNG Linux unterstutzt sowohl nach POSIX zuverlassige Signale (im Folgenden: >>Standard-Signale<<) und POSIX-Echtzeit-Signale. Signalzuordnung (disposition) Jedes Signal hat eine aktuelle Zuordnung. Sie legt fest, wie sich der Prozess verhalt, wenn er das Signal erhalt. Die Eintrage in der >>Aktion<<-Spalte in der folgenden Tabelle legen die Standardzuordnung fur jedes Signal fest: Term Standardaktion ist der Abbruch des Prozesses. Ign Standardaktion ist, das Signal zu ignorieren. Core Die Standardaktion ist der Abbruch des Prozesses und das Erstellen eines Speicherauszugs (siehe core(5)). Stop Die Standardaktion ist, den Prozess anzuhalten. Cont Die Standardaktion ist, einen angehaltenen Prozess fortzusetzen. Ein Prozess kann die Zuordnung eines Signals mit Hilfe von sigaction(2) oder signal(2) andern. (Letzteres ist schlechter portierbar bei der Realisierung von Signal-Handlern; siehe signal(2) fur Details.) Mit diesen Systemaufrufen kann ein Prozess eine der folgenden Verhaltensweisen bei Erhalt eines Signals auswahlen: die Standardaktion ausfuhren, 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. Standardmassig wird ein Signal-Handler auf dem normalen Prozess-Stack aufgerufen. Man kann es einrichten, dass der Signal-Handler einen alternativen Stack benutzt; vgl. sigaltstack(2) fur eine Erorterung, wie das gemacht wird und wann es nutzlich sein konnte. Die Signalzuordnung ist ein prozessbezogenes Attribut; in einer Multithread-Anwendung ist die Zuordnung eines bestimmten Signales fur alle Threads gleich. Ein mittels fork(2) erstellter Kindprozess erbt eine Kopie der Signalzuordnungen seines Elternprozesses. Wahrend eines execve(2) werden die Zuordnungen von verwalteten Signalen auf die Vorgabe zuruckgesetzt; die Zuordnung ignorierter Signale werden unverandert gelassen. Ein Signal senden Die folgenden Systemaufrufe und Bibliotheksfunktionen ermoglichen 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 pidfd_send_signal(2) sendet ein Signal an einen Prozess, der durch einen PID-Dateideskriptor identifiziert ist. killpg(3) sendet ein Signal an alle Mitglieder einer bestimmten Prozessgruppe pthread_kill(3) sendet ein Signal an einen bestimmten POSIX-Thread im gleichen Prozess wie die aufrufende Routine tgkill(2) Es wird ein Signal an einen bestimmten Thread in einem bestimmten Prozess gesendet. (Mit diesem Systemaufruf wird pthread_kill(3) realisiert.) sigqueue(3) sendet ein Echtzeit-Signal und zugehorige Daten an einen bestimmten Prozess Warten auf ein abzufangendes Signal Die folgenden Systemaufrufe setzen die Ausfuhrung des aufrufenden Threads aus, bis ein Signal abgefangen wird (oder ein nicht abgefangenes Signal den Prozess beendet): pause(2) setzt die Ausfuhrung aus, bis irgendein Signal abgefangen wird. sigsuspend(2) andert zeitweise die Signalmaske (siehe unten) und setzt die Ausfuhrung 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 heisst, die Ausfuhrung wird blockiert, bis das Signal gesendet wird. Dann liefert der Kernel Informationen uber das Signal an den Aufrufenden. Es gibt zwei allgemeine Moglichkeiten, das zu tun: o sigwaitinfo(2), sigtimedwait(2) und sigwait(3) setzen die Ausfuhrung aus, bis ein Signal gesendet wird, dass zu einer festgelegen Gruppe von Signalen gehort. Jeder dieser Aufrufe gibt Informationen uber das empfangene Signal zuruck. o signalfd(2) gibt einen Dateideskriptor zuruck. Mit ihm konnen Informationen uber Signale gelesen werden, die dem Aufrufenden ubermittelt 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) zuruckgegebene Puffer enthalt 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 (spater/verzogert) freigegeben wurde. Zwischen dem Zeitpunkt seiner Erzeugung und dem Zeitpunkt seines Versands wird es anstehend (pending) genannt. Jeder Thread in einem Prozess hat eine unabhangige 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 Signalmaske des Elternprozeses; die Signalmaske wird uber execve(2) hinweg erhalten. 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 anhangig ist). Ein Signal kann Prozess-orientiert sein, da es vom Kernel fur einen Grund ausser einer Hardware-Ausnahmebehandlung erzeugt wurde oder da es mittels kill(2) oder sigqueue(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 Ausfuhrung einer bestimmten Anweisung in Maschinensprache erstellt wurde, die eine Hardware-Ausnahmebehandlung ausloste (z.B. SIGSEGV fur einen ungultigen Speicherzugriff oder SIGFPE fur einen mathematischen Fehler) oder da es mit Schnittstellen wie tgkill(2) oder pthread_kill(3) auf einen bestimmten Thread zielte. 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 wahlt der Kernel einen beliebigen Thread aus, an den er das Signal ausliefert. Ein Thread kann die aktuell fur ihn anstehenden Gruppe von Signale mit sigpending(2) ermitteln. Das sind einerseits die fur diesen Thread und andererseits die fur seinen Prozess bestimmten Signale. Ein mittels fork(2) erstellter Kindprozess hat anfanglich eine leere anhangende Signalgruppe; die anhangende Signalgruppe wird uber execve(2) hinweg erhalten. Ausfuhrung eines Signal-Handlers Immer wenn es einen Ubergang von der Kernelmodus-Ausfuhrung zu der Anwendungsraum-Ausfuhrung gibt (z.B bei der Ruckkehr aus einem Systemaufruf oder Einplanung eines Threads auf einer CPU), pruft der Kernel, ob es ein anhangendes, nicht blockiertes Signal gibt, fur das der Prozess einen Signal-Handler etabliert hat. Falls es ein solches anhangendes Signal gibt, passieren die folgenden Schritte: (1) Der Kernel fuhrt die notwendigen Vorbereitungsschritte zur Ausfuhrung des Signal-Handlers durch: (1.1) Das Signal wird aus der Menge der anhangenden Signale entfernt. (1.2) Falls der Signal-Handler durch einen Aufruf von sigaction(2) installiert wurde, der den Schalter SA_ONSTACK festlegte, und der Thread uber einen definierten alternativen Signal-Stack verfugt (mittels sigaltstack(2)), dann wird der Stack installiert. (1.3) Verschiedene Teile des Signal-bezogenen Kontextes werden in ein besonderes Frame gespeichert, das auf dem Stack erstellt wird. Die gespeicherten Informationen beinhalten: o das Programmzahlregister (d.h. die Adresse der nachsten Anweisung in dem Hauptprogramm, die ausgefuhrt werden soll, wenn der Signal-Handler zuruckkehrt); o architekturabhangige Registerzustande, die zur Wiederaufnahme des unterbrochenen Programms benotigt werden; o die aktuelle Signal-Maske des Threads; o die alternativen Signal-Stack-Einstellungen des Threads. (Falls der Signal-Handler mittels des Schalters SA_SIGINFO von sigaction(2) installiert wurde, dann kann auf die obigen Informationen uber das Objekt ucontext_t, auf das durch das dritte Argument des Signal-Handlers gezeigt wird, zugegriffen werden.) (1.4) Jedes bei der Registrierung des Handlers mit sigprocmask(2) in act->sa_mask festgelegte Signal wird zu der Signal-Maske des Threads hinzugefugt. Das auszuliefernde Signal wird auch zu der Signal-Maske hinzugefugt, ausser SA_NODEFER wurde bei der Registrierung des Handlers festgelegt. Diese Signale sind daher wahrend der Ausfuhrung des Handlers blockiert. (2) Der Kernel konstruiert ein Frame fur den Signal-Handler auf dem Stack. Der Kernel setzt den Programmzahler fur den Thread, so dass er auf die erste Anweisung der Signal-Handler-Funktion zeigt, und konfiguriert die Rucksprungadresse fur diese Funktion, so dass sie auf ein Stuck Code im Anwendungsraum zeigt, das als Signaltrampolin bekannt ist (beschrieben in sigreturn(2)). (3) Der Kernel ubergibt die Steuerung zuruck an den Anwendungsraum, wo mit der Ausfuhrung beim Anfang der Signal-Handler-Funktion fortgefahren wird. (4) Wenn der Signal-Handler zuruckkehrt, wird die Steuerung an den Signal-Trampolin-Code ubergeben. (5) Das Signaltrampolin ruft den Systemaufruf sigreturn(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 sigreturn(2) ubergibt der Kernel die Steuerung wieder an den Anwendungsraum zuruck und der Thread fahrt mit der Ausfuhrung an dem Punkt fort, an dem er durch den Signal-Handler unterbrochen wurde. Beachten Sie, dass der abschliessende Schritt nicht ausgefuhrt wird, falls der Signal-Handler nicht zuruckkehrt (z.B. weil die Steuerung mittels siglongjmp(3) aus dem Handler herausverlegt wurde oder der Handler mittels execve(2) ein neues Programm ausfuhrt). In solchen Szenarien ist es insbesondere die Verantwortung des Programmierers, den Zustand der Signalmaske (mittels sigprocmask(2)) wiederherzustellen, falls gewunscht wird, die Blockierung der Signale aufzuheben, die beim Eintritt in den Signal-Handler blockiert wurden. (Beachten Sie, dass siglongjmp(3) die Signal-Maske wiederherstellen konnte oder auch nicht, abhangig vom Wert savesigs, der beim entsprechenden Aufruf von sigsetjmp(3) festgelegt wurde.) Vom Standpunkt des Kernels aus ist die Ausfuhrung des Signal-Handler-Codes genau das gleiche wie die Ausfuhrung jedes anderen Codes im Anwendungsraum. Dies bedeutet, dass der Kernel keinerlei besondere Zustandsinformationen aufzeichnet, die anzeigen, dass der Thread sich derzeit in der Ausfuhrung 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 konnen, wird daher durch den Anwendungsraum-Stack begrenzt (und unterliegt daher dem Design der Software). Standard-Signale Linux untersutzt die nachfolgend aufgefuhrten Standard-Signale. Die zweite Spalte der Tabelle zeigt an, welcher Standard (falls vorhanden) das Signal festlegt: >>P1990<< zeigt an, dass das Signal in dem ursprunglichen Standard POSIX.1-1990 beschrieben wurde; >>P2001<< zeigt an, dass das Signal in SUSv2 und POSIX.1-2001 hinzugefugt wurde. Signal Standard Aktion Kommentar ------------------------------------------------------------------------------------------ SIGABRT P1990 Core Abbruchsignal von abort(3) SIGALRM P1990 Term Timersignal von alarm(2) SIGBUS P2001 Core Bus-Fehler (Speicherzugriffsfehler) SIGCHLD P1990 Ign Kindprozess angehalten oder beendet SIGCLD - Ign ein Synonym fur SIGCHLD SIGCONT P1990 Cont fortsetzen, wenn angehalten SIGEMT - Term Emulator-Ausnahmebehandlung SIGFPE P1990 Core Fliesskomma-Ausnahmefehler SIGHUP P1990 Term Verbindung am steuernden Terminal beendet (aufgehangt) oder der steuernde Prozess wurde beendet SIGILL P1990 Core ungultiger Befehl SIGINFO - ein Synonym fur SIGPWR SIGINT P1990 Term Unterbrechung von der Tastatur SIGIO - Term E/A jetzt moglich (4.2BSD) SIGIOT - Core IOT-Ausnahmebehandlung; ein Synonym fur SIGABRT SIGKILL P1990 Term Kill-Signal SIGLOST - Term Dateisperre verloren/aufgehoben (nicht verwandt) SIGPIPE P1990 Term defekte Pipe: Schreiben in eine Pipe ohne Leser; siehe pipe(7) SIGPOLL P2001 Term abfragbares Ereignis (Sys V) Synonym fur SIGIO SIGPROF P2001 Term Profiling-Timer abgelaufen SIGPWR - Term Stromausfall (System V) SIGQUIT P1990 Core Abbruch von der Tastatur SIGSEGV P1990 Core ungultige Speicherreferenz SIGSTKFLT - Term Stack-Ausnahmebehandlung am Koprozessor (nicht verwendet) SIGSTOP P1990 Stop Stop process SIGTSTP P1990 Stop Stop am Terminal eingegeben SIGSYS P2001 Core Ungultiger Systemaufruf (SVr4); siehe auch seccomp(2) SIGTERM P1990 Term Beendigungssignal (termination signal) SIGTRAP P2001 Core Trace-/Haltepunkt-Ausnahmebehandlung SIGTTIN P1990 Stop Terminal-Eingabe fur Hintergrundprozess SIGTTOU P1990 Stop Terminal-Ausgabe fur Hintergrundprozess SIGUNUSED - Core synonym mit SIGSYS 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 uberschritten (4.2BSD) siehe setrlimit(2) SIGXFSZ P2001 Core Dateigrossenbegrenzung uberschritten (4.2BSD) siehe setrlimit(2) SIGWINCH - Ign Anderung der Fenstergrosse (4.3BSD, Sun) Die Signale SIGKILL und SIGSTOP konnen nicht abgefangen, blockiert oder ignoriert werden. Bis einschliesslich Linux 2.2 war das Standardverhalten fur 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 fur 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. 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 standardmassig auf verschiedenen anderen UNIX-Systemen ignoriert. Warteschlange und Auslieferungssemantik fur Standard-Signale Falls fur einen Prozess mehrere Standard-Signale anhangig sind, ist die Reihenfolge, in der diese Signale ausgeliefert werden, nicht spezifiziert. Standard-Signale kennen keine Warteschlange. Falls mehrere Instanzen eines Standard-Signals erstellt werden, wahrend dieses Signal blockiert ist, wird nur eine Instanz des Signals als anhangig markiert (und das Signal wird ausgeliefert, genau wenn die Blockade aufgehoben wird). Im Fall, bei dem ein Standard-Signal bereits anhangig ist, wird die dem Signal zugehorige Struktur siginfo_t (siehe sigaction(2)) nicht bei der Ankunft nachfolgender Instanzen des gleichen Signals uberschrieben. Daher wird der Prozess die Informationen, die zu der ersten Instanz des Signals gehoren, erhalten. Signalnummerierung fur Standard-Signale Der numerische Wert fur 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 fur Alpha und SPARC; der dritte fur MIPS und der letzte fur PARISC. Ein Bindestrich (-) zeigt an, dass ein Signal auf der entsprechenden Architektur nicht vorhanden ist. Signal x86/ARM Alpha/ MIPS PARISC Hinweise die meisten anderen SPARC ------------------------------------------------------------------------------ SIGHUP 1 1 1 1 SIGINT 2 2 2 2 SIGQUIT 3 3 3 3 SIGILL 4 4 4 4 SIGTRAP 5 5 5 5 SIGABRT 6 6 6 6 SIGIOT 6 6 6 6 SIGBUS 7 10 10 10 SIGEMT - 7 7 - SIGFPE 8 8 8 8 SIGKILL 9 9 9 9 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 - - 7 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 Beachten Sie Folgendes: o Wenn das Signal definiert ist, ist SIGUNUSED synonym zu SIGSYS. Seit Glibc 2.26 ist SIGUNUSED auf keiner Architektur mehr definiert. o Signal 29 ist SIGINFO / SIGPWR (synonym fur den gleichen Wert) auf einer Alpha-Maschine, aber SIGLOST auf einer SPARC. Echtzeit-Signale Beginnend mit Linux 2.2 unterstutzt Linux Echtzeit-Signale, wie sie ursprunglich in den POSIX.1b-Echtzeit-Erweiterungen definiert wurden (und jetzt in POSIX.1-2001 enthalten sind). Die Bereich der unterstutzten Echtzeit-Signale wird von den Makros SIGRTMIN und SIGRTMAX definiert. POSIX.1-2001 verlangt, dass eine Umsetzung mindestens _POSIX_RTSIG_MAX (8) Echtzeit-Signale unterstutzt. Der Linux-Kernel unterstutzt eine Reihe von 33 verschiedenen Echtzeit-Signalen, nummeriert von 32 bis 64. Doch die Glibc-Umsetzung der POSIX-Threads verwendet intern zwei (fur NPTL) oder drei (fur LinuxThreads) Echtzeit-Signale (siehe pthreads (7)) und stellt den Wert von SIGRTMIN passend (auf 34 oder 35 ein). Da die Zahl der verfugbaren Echtzeit-Signale je nach Glibc-Threading-Implementierung variiert und diese Variation (entsprechend dem verfugbaren Kernel und der Glibc) zur Laufzeit auftreten kann und tatsachlich die verfugbaren 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 uberpruft werden, ob (SIGRTMIN+n) SIGRTMAX nicht ubersteigt. Im Gegensatz zu Standard-Signalen haben Echtzeit-Signale keine vordefinierten Bedeutungen: der gesamte Satz von Echtzeit-Signalen kann fur anwendungsspezifische Zwecke genutzt werden. Die Standardaktion fur ein nicht abgefangenes Echtzeit-Signal ist der Abbruch des Prozesses. Echtzeit-Signale zeichnen sich durch folgende Merkmale aus: o Von Echtzeit-Signalen konnen mehrere Instanzen anstehen. Im Gegensatz dazu wird beim Versand mehrerer Instanzen eines Standard-Signals, wahrend das Signal aktuell blockiert ist, nur eine Instanz weiter anstehen. o 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 fur sigaction(2) einen Handler fur dieses Signal implementiert, kann dieser Wert aus dem si_value-Feld der siginfo_t-Struktur (das zweite Argument des Handlers) bestimmt werden. Daruber hinaus konnen die Felder si_uid und si_pid dieser Struktur verwendet werden, um die PID und reale Benutzerkennung des Prozesses zu erhalten, der das Signal erzeugt hat. o 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 hochste Prioritat.) Im Gegensatz dazu ist die Reihenfolge der Zustellung mehrerer fur einen Prozess anstehender Standard-Signale nicht festgelegt. Wenn sowohl Standard- als auch Echtzeit-Signale fur 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 ermoglichen. Allerdings macht Linux das anders. Bis einschliesslich Linux 2.6.7 legt Linux eine systemweite Obergrenze fur die Anzahl wartender Echtzeit-Signale fur alle Prozesse fest. Diese Grenze kann eingesehen und (mit entsprechenden Rechten) durch die Datei /proc/sys/kernel/rtsig-max geandert 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 fur anstehende Signale in der Warteschlange festlegt, ersetzt (siehe setrlimit(2)). Die Erganzung um Echtzeitsignale erforderte die Verbreiterung der Signalmengenstruktur (sigset_t) von 32 auf 64 Bit. Konsequenterweise wurden viele Systemaufrufe durch neue Systemaufrufe abgelost, die die grosseren Signalmengen unterstutzten. Die alten und neuen Systemaufrufe sind wie folgt: Linux 2.0 und alter Linux 2.2 und neuer sigaction(2) rt_sigaction(2) sigpending(2) rt_sigpending(2) sigprocmask(2) rt_sigprocmask(2) sigreturn(2) rt_sigreturn(2) sigsuspend(2) rt_sigsuspend(2) sigtimedwait(2) rt_sigtimedwait(2) Unterbrechung von Systemaufrufen und Bibliotheksfunktionen durch Signal-Handler Wenn ein Signal-Handler aufgerufen wird, wahrend ein Systemaufruf oder Bibliotheksfunktionsaufruf blockiert ist, wird entweder: o nach Abschluss des Signal-Handlers der Aufruf neu gestartet oder o der Aufruf schlagt mit dem Fehler EINTR fehl. Welche dieser beiden Verhaltensweisen eintritt, hangt 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 erortert. Wenn ein blockierter Aufruf einer der folgenden Schnittstellen von einem Signal-Handler unterbrochen wird, wird der Aufruf nach der Ruckkehr aus dem Signal-Handler erneut gestartet, wenn der Schalter SA_RESTART verwendet wurde; anderenfalls schlagt der Aufruf mit dem Fehler EINTR fehl: o Aufrufe von read(2), readv(2), write(2), writev(2) und ioctl(2) fur >>langsame<< Gerate. Bei >>langsamen<< Geraten kann ein E-/A-Aufruf fur eine unbestimmte Zeit zu einer Blockade fuhren. Zu ihnen gehoren beispielsweise Terminals, Pipes und Sockets. Hat ein E-/A-Aufruf fur ein langsames Gerat schon Daten ubertragen und wird durch einen Signal-Handler unterbrochen, wird der Aufruf mit einem Erfolgs-Status abgeschlossen (normalerweise ist das die Zahl ubertragener Bytes). Beachten Sie, dass eine (lokale) Festplatte nach dieser Definition kein langsames Gerat ist. E/A-Aktionen auf Fesplattengeraten werden durch Signale nicht unterbrochen. o open(2), wenn er blockieren kann (z. B. beim Offnen eines FIFOs; siehe fifo(7)). o wait(2), wait3(2), wait4(2), waitid(2) und waitpid(2). o 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 fur den Socket eine Zeitbegrenzung (Timeout) festgelegt (siehe unten). o Dateisperrende Schnittstellen: flock(2) und die Aktionen F_SETLKW und F_OFD_SETLKW von fcntl(2). o POSIX-Schnittstellen fur Nachrichten-Warteschlangen: mq_receive(3), mq_timedreceive(3), mq_send(3), and mq_timedsend(3). o futex(2) FUTEX_WAIT (seit Linux 2.6.22; vorher immer Fehlschlag mit EINTR). o io_getevents(2) o pthread_mutex_lock(3), pthread_cond_wait(3) und verwandte APIs. o futex(2) FUTEX_WAIT_BITSET. o POSIX-Semaphor-Schnittstellen: sem_wait(3) und sem_timedwait(3) (seit Linux 2.6.22; vorher immer Fehlschlag mit EINTR). o read(2) von einem inotify(7)-Dateideskriptor (seit Linux 3.8; vorher immer Fehlschlag mit EINTR). Folgende Schnittstellen werden nach einer Unterbrechung durch einen Signal-Handler, unabhangig von der Verwendung von SA_RESTART nie erneut gestartet; sie schlagen immer mit dem Fehler EINTR fehl: o >>Eingabe<<-Socket-Schnittstellen, wenn fur 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). o >>Ausgabe<<-Socket-Schnittstellen, wenn fur den Socket mittels setsockopt(2) eine Zeitbegrenzung (Timeout, SO_RCVTIMEO) festgelegt wurde: connect(2), send(2), sendto(2) und sendmsg(2). o Schnittstellen, mit denen auf Signale gewartet wird: pause(2), sigsuspend(2), sigtimedwait(2) und sigwaitinfo(2). o Schnittstellen, die Dateideskriptoren mehrfach nutzen: epoll_wait(2), epoll_pwait(2), poll(2), ppoll(2), select(2) und pselect(2). o System-V-IPC-Schnittstellen: msgrcv(2), msgsnd(2), semop(2), and semtimedop(2). o Schlaf-Systemaufrufe: clock_nanosleep(2), nanosleep(2), and usleep(3). o io_getevents(2) Die Funktion sleep(3) wird ebenfalls niemals neu gestartet, wenn sie durch einen Handler unterbrochen wurde, wird aber erfolgreich verlassen: Der Ruckgabewert ist die Zeit, die noch geschlafen werden sollte. Unter bestimmten Umstanden kann die Benachrichtigungsfunktionalitat im Benutzerraum von seccomp(2) zum Neustart von Systemaufrufen fuhren, die andernfalls niemals durch SA_RESTART neugestartet wurden; fur Details siehe seccomp_unotify(2). Unterbrechung von Systemaufrufen und Bibliotheksfunktionen durch Stop-Signale Auf Linux konnen 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 wird von POSIX.1 nicht gebiligt und tritt nicht auf anderen Systemen auf. Die folgenden Linux-Schnittstellen zeigen dieses Verhalten: o >>Eingabe<<-Socket-Schnittstellen, wenn fur 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). o >>Ausgabe<<-Socket-Schnittstellen, wenn fur den Socket mittels setsockopt(2) eine Zeitbegrenzung (Timeout, SO_RCVTIMEO) festgelegt wurde: connect(2), send(2), sendto(2) und sendmsg(2), falls eine Sendezeituberschreitung (SO_SNDTIMEO) gesetzt wurde. o epoll_wait(2), epoll_pwait(2). o semop(2), semtimedop(2). o sigtimedwait(2), sigwaitinfo(2). o Linux 3.7 und alter: read(2) von einem inotify(7)-Dateideskriptor o Linux 2.6.21 und fruher: futex(2) FUTEX_WAIT, sem_timedwait(3), sem_wait(3). o Linux 2.6.8 und fruher: msgrcv(2), msgsnd(2). o Linux 2.4 und fruher: nanosleep(2). STANDARDS POSIX.1, mit den beschriebenen Ausnahmen ANMERKUNGEN Fur eine Diskussion asynchron-Signal-sicherer Funktionen, siehe signal-safety(7). Die Datei /proc/PID/task/[TID]/status enthalt verschiedene Felder, die die Signale, die ein Thread blockiert (SigBlk), abfangt (SigCgt) oder ignoriert (SigIgn) zeigt. (Die Gruppe der abgefangenen oder ignorierten Signale wird fur alle Threads eines Prozesses identisch sein.) Andere Felder zeigen die Gruppe der anhangenden Signale, die fur den Thread bestimmt sind (SigPnd) sowie die Gruppe der anhangenden Signale, die fur den Prozess als ganzes bestimmt sind (ShdPnd). Die entsprechenden Felder in /proc/PID/status zeigen die Informationen fur den Haupt-Thread. Siehe proc(5) fur weitere Details. FEHLER Es gibt sechs Signale, die als Konsequenz aus einer Hardware-Ausnahmebehandlung ausgeliefert werden konnen: SIGBUS, SIGEMT, SIGFPE, SIGILL, SIGSEGV und SIGTRAP. Welches dieser Signale fur eine bestimmte Hardware-Ausnahmebehandlung ausgeliefert wird, ist nicht dokumentiert und ergibt nicht immer Sinn. Zum Beispiel kann ein ungultiger Speicherzugriff, der die Auslieferung von SIGSEGV auf einer CPU-Architektur hervorruft, die Auslieferung von SIGBUS auf einer anderen Architektur (oder andersherum) hervorrufen. Als weiteres Beispiel lost die Verwendung der X86-int-Anweisung mit einem verbotenen Argument (jeder Zahl ausser 3 und 128) die Auslieferung von SIGSEGV aus, obwohl SIGILL mehr Sinn ergabe, aufgrund der Art, wie die CPU die verbotene Operation an den Kernel berichtet. SIEHE AUCH kill(1), clone(2), getrlimit(2), kill(2), pidfd_send_signal(2), restart_syscall(2), rt_sigqueueinfo(2), setitimer(2), setrlimit(2), sgetmask(2), sigaction(2), sigaltstack(2), signal(2), signalfd(2), sigpending(2), sigprocmask(2), sigreturn(2), sigsuspend(2), sigwaitinfo(2), abort(3), bsd_signal(3), killpg(3), longjmp(3), pthread_sigqueue(3), raise(3), sigqueue(3), sigset(3), sigsetops(3), sigvec(3), sigwait(3), strsignal(3), swapcontext(3), sysv_signal(3), core(5), proc(5), nptl(7), pthreads(7), sigevent(3type) UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Martin Eberhard Schauer , Dr. Tobias Quathamer und Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . Linux man-pages 6.06 31. Oktober 2023 signal(7)