Provided by: manpages-de-dev_4.23.1-1_all bug

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