Provided by: manpages-de-dev_4.13-4_all bug

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 Grund anzugeben.

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

Linux                                          15. September 2017                                      SIGNAL(2)