signal

SIGNAL(2)                   Linux-Programmierhandbuch                  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
       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.

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

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.

       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().

       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.

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)

KOLOPHON
       Diese Seite ist Teil der Veröffentlichung 5.11 des Projekts
       Linux-man-pages. 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/.


Ü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⟩.



Linux                             22. März 2021                        SIGNAL(2)