SIGNAL(2)

BEZEICHNUNG
signal - Handhabung von Signalen in ANSI C

ÜBERSICHT
#include <signal.h>

typedef void (*sighandler_t)(int);

sighandler_t signal(int signum, sighandler_t handler);

BESCHREIBUNG
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 zugewiesen wurde, wird das Signal ignoriert.

*   Falls SIG_DFL zugewiesen wurde, wird die standardmäßig dem Signal zugewiesene Aktion ausgeführt, wenn das Signal eintrift (siehe signal(7)).

*   Falls eine Funktion zugewiesen 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 Grund anzugeben.

FEHLER

EINVAL
    signum ist ungültig.

KONFORM ZU
C89, C99, POSIX.1-2001.

ANMERKUNGEN
Die Auswirkungen von signal() in einem Multithread-Prozess sind nicht spezifiziert.

Gemäß POSIX ist das Verhalten eines Prozesses nicht definiert, nachdem er ein SIGFPE-Signal, ein SIGILL-Signal oder ein SIGSEGVSignal, das nicht von kill(2) oder raise(3) erzeugt wurde, ignoriert. Eine Integer-Division durch Null hat ein undefiniertes Ergebnis. Auf einigen Architekturen wird die Division ein SIGFPE-Signal erzeugen. (Auch die Division der größten negativen Zahl durch -1 kann ein SIGFPE auslösen.) Ein Ignorieren dieses Signals könnte zu einer Endlosschleife führen.

Siehe sigaction(2) für Einzelheiten des Geschehens, wenn SIGCHLD auf SIG_IGN gesetzt wird.

Siehe signal(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.

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 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 Zuweisung 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(). 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; System V also provides these semantics for signal(). This was bad because the signal might be delivered again before the handler had a chance to reestablish itself. Furthermore, rapid deliveries of the same signal could result in recursive invocations of the handler. 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:

*   The kernel's signal() system call provides System V semantics.

*   Standardmäßig nutzt in Glibc 2 und später die signal()-Wrapper-Funktion nicht den Kernel-Systemaufruf. Stattdessen ruft sie sigaction (2) mit Flags auf, welche BSD-Semantik bereitstellen. Dieses Standardverhalten wird so lange bereitgestellt, solange das Feature-Test-Makro _BSD_SOURCE definiert ist. Standardmäßig ist _BSD_SOURCE definiert. Es ist auch implizit definiert, wenn man _GNU_SOURCE definiert. Natürlich kann es auch explizit definiert werden.

    On glibc 2 and later, if the _BSD_SOURCE feature test macro is not defined, then signal() provides System V semantics. (The default implicit definition of _BSD_SOURCE is not provided if one invokes gcc(1) in one of its standard modes (-std=xxx or -ansi) or defines various other feature test macros such as _POSIX_SOURCE, _XOPEN_SOURCE, or _SVID_SOURCE; see feature_test_macros(7).)

*   The signal() function in Linux libc4 and libc5 provide System V semantics. If one on a libc5 system includes <bsd/signal.h> instead of <signal.h>, then signal() provides BSD semantics.

SIEHE AUCH
kill(1), alarm(2), kill(2), killpg(2), pause(2), sigaction(2), signalfd(2), sigpending(2), sigprocmask(2), sigsuspend(2), bsd_signal(3), raise(3), siginterrupt(3), sigqueue(3), sigsetops(3), sigvec(3), sysv_signal(3), signal(7)

KOLOPHON
This page is part of release 3.70 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at http://www.kernel.org/doc/man-pages/.

ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von René Tschirley <gremlin@cs.tu-berlin.de>, Martin Schulze <joey@infodrom.org> und Martin Eberhard Schauer <Martin.E.Schauer@gmx.de> erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an <debian-l10n-german@lists.debian.org>.