Provided by: manpages-de-dev_4.25.1-1_all 
BEZEICHNUNG
signal - Handhabung von Signalen in ANSI C
BIBLIOTHEK
Standard-C-Bibliothek (libc, -lc)
ÜBERSICHT
#include <signal.h> typedef void (*sighandler_t)(int); sighandler_t signal(int signum, sighandler_t handler);
BESCHREIBUNG
WARNUNG: Das Verhalten von signal() unterscheidet sich zwischen UNIX-Versionen und hat sich historisch
auch zwischen verschiedenen Linux-Versionen geändert. Vermeiden Sie den Einsatz dieser Funktion und
verwenden Sie stattdessen sigaction(2); siehe Portabilität weiter unten.
signal() ordnet dem Signal signum den handler zu. Das ist entweder SIG_IGN, SIG_DFL oder die Adresse
einer vom Programmierer definierten Funktion (eines »Signal Handlers«).
Falls dem Prozess das Signal signum zugestellt wird, wird einer der folgenden Fälle eintreten:
* Falls SIG_IGN zugeordnet wurde, wird das Signal ignoriert.
* Falls SIG_DFL zugeordnet wurde, wird die standardmäßig dem Signal zugewiesene Aktion ausgeführt, wenn
das Signal eintrift (siehe signal(7)).
* Falls eine Funktion zugeordnet wurde, dann wird zuerst entweder die Zuweisung auf SIG_DFL
zurückgesetzt oder das Signal wird blockiert (siehe Portability unten) und anschließend handler mit
dem Argument signum aufgerufen. Falls der Aufruf des Handlers ein Blockieren des Signals verursachte,
wird die Blockade nach der Rückkehr aus dem Handler aufgehoben.
Die Signale SIGKILL und SIGSTOP können nicht abgefangen oder ignoriert werden.
RÜCKGABEWERT
signal() liefert den vorherigen Signal Handler zurück oder im Fehlerfall SIG_ERR. Im Fehlerfall wird
errno gesetzt, um den Fehler anzuzeigen.
FEHLER
EINVAL signum ist ungültig.
VERSIONEN
Die Verwendung von sighandler_t ist eine GNU-Erweiterung, die durch die Definition von _GNU_SOURCE
verfügbar wird; Glibc definiert zusätzlich (das von BSD abgeleitete) sig_t, wenn _BSD_SOURCE (Glibc 2.19
und älter) oder _DEFAULT_SOURCE (Glibc 2.19 und neuer) definiert wird. Ohne die Nutzung eines solches
Typs ist die Deklaration von signal() etwas schwerer zu lesen:
void ( *signal(int signum, void (*handler)(int)) ) (int);
Portabilität
Die einzige portable Verwendung von signal() ist die Zuordnung von SIG_DFL oder SIG_IGN zu einem Signal.
Die Semantik bei der Einrichtung eines Signal Handlers mittels signal() unterscheidet sich zwischen
Systemen (und POSIX.1 erlaubt diese Unterschiede explizit); verwenden Sie die Funktion nicht für diesen
Zweck.
POSIX.1 löste das Portabilitätschaos durch die Beschreibung von sigaction(2), die eine explizite
Kontrolle der Semantik beim Aufruf eines Signal-Handlers ermöglicht; verwenden Sie diese Schnittstelle
anstatt von signal().
STANDARDS
C11, POSIX.1-2008.
GESCHICHTE
C89, POSIX.1-2001.
In den ursprünglichen UNIX-Systemen wurde beim Aufruf eines mittels signal() zugeordneten Handlers die
Signalbearbeitung wieder auf SIG_DFL zurückgesetzt und das System blockierte weitere Instanzen des
Signals nicht mehr. Dies ist äquivalent zum Aufruf von sigaction(2) mit den folgenden Schaltern:
sa.sa_flags = SA_RESETHAND | SA_NODEFER;
Auch System V bietet diese Semantik für signal(). Das war schlecht, weil das Signal wieder eintreffen
konnte, bevor der Signal Handler Gelegenheit hatte, sich erneut einzurichten. Darüber hinaus konnten
schnell aufeinander folgende Zustellungen des gleichen Signals zu rekursiven Aufrufen des Handlers
führen.
BSD verbesserte die Situation, änderte aber unglücklicherweise dabei auch die Semantik der bestehenden
signal()-Schnittstelle. Unter BSD wird beim Aufruf eines Signal-Handlers dieser für das Signal
beibehalten und die Zustellung weiterer Instanzen des Signals wird blockiert, solange der Handler noch
läuft. Desweiteren werden bestimmte blockierende Systemaufrufe automatisch neu gestartet, falls sie durch
einen Signal-Handler (siehe signal(7)) unterbrochen wurden. Die BSD-Semantik ist äquivalent zum Aufruf
von sigaction(2) mit den folgenden Schaltern:
sa.sa_flags = SA_RESTART;
Die Situation unter Linux ist wie folgt:
• Das signal()-System des Kernels stellt System-V-Semantik bereit.
• Standardmäßig nutzt in Glibc 2 und neuer die signal()-Wrapper-Funktion nicht den Kernel-Systemaufruf.
Stattdessen ruft sie sigaction (2) mit Schaltern auf, welche BSD-Semantik bereitstellen. Dieses
Standardverhalten wird so lange bereitgestellt, solange ein geeignetes Feature-Test-Makro definiert
ist: _BSD_SOURCE unter Glibc 2.19 und älter oder _DEFAULT_SOURCE unter Glibc 2.19 und neuer.
(Standardmäßig werden diese Makros definiert; siehe feature_test_macros(7) für Details.) Falls ein
solches Feature-Test-Makro nicht definiert ist, wird signal() die System-V-Semantik bereitstellen.
ANMERKUNGEN
Die Auswirkungen von signal() in einem Multithread-Prozess sind nicht spezifiziert.
Laut POSIX ist das Verhalten eines Prozesses undefiniert, nachdem er ein Signal SIGFPE, SIGILL oder
SIGSEGV ignoriert hat, das nicht von kill(2) oder raise(3) erstellt wurde. Ganzzahldivision durch Null
hat ein undefiniertes Ergebnis. Auf einigen Architekturen wird dies ein Signal SIGFPE hervorrufen. (Auch
kann die Division der größten negativen Ganzzahl durch -1 SIGFPE hervorrufen.) Wird dieses Signal
ignoriert, kann eine Endlosschleife auftreten.
Siehe sigaction(2) für Einzelheiten des Geschehens, wenn die Zuordnung SIGCHLD auf SIG_IGN gesetzt wird.
Siehe signal-safety(7) für eine Liste von Funktionen, die sicher mit asynchronen Signalen umgehen können
und daher sicher aus einem Signal Handler heraus aufgerufen werden können.
SIEHE AUCH
kill(1), alarm(2), kill(2), pause(2), sigaction(2), signalfd(2), sigpending(2), sigprocmask(2), sigsuspend(2), bsd_signal(3), killpg(3), raise(3), siginterrupt(3), sigqueue(3), sigsetops(3), sigvec(3), sysv_signal(3), signal(7)
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von René Tschirley <gremlin@cs.tu-berlin.de>, Martin Schulze <joey@infodrom.org>, Martin Eberhard Schauer <Martin.E.Schauer@gmx.de> und Mario Blättermann <mario.blaettermann@gmail.com> erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.