Provided by: manpages-de-dev_4.27.0-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>,  Mario  Blättermann
       <mario.blaettermann@gmail.com> und Helge Kreutzmann <debian@helgefjell.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 die
       Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org.

Linux man-pages 6.9.1                              2. Mai 2024                                         signal(2)