Erklärt die Erzeugung und Handhabung von Linux-Signalen

Der Signalisierungsmechanismus im Linux-Kernel ermöglicht laufenden Anwendungen, das System asynchron zu benachrichtigen, wenn ein neues Ereignis eintritt. Aufgrund seiner Natur ist dieser Signalisierungsmechanismus allgemein als Software-Interrupts bekannt. Genau wie Hardware-Interrupts unterbrechen Signale den normalen Ablauf einer Anwendung, und es ist unvorhersehbar, wann eine Anwendung ein Signal empfängt.

Lassen Sie uns tief in den Signalisierungsmechanismus von Linux eintauchen und verstehen, was hinter den Kulissen vor sich geht.

Grundlegende Signalkonzepte in Linux

Unter Linux erzeugen Prozesse Signale in drei grundlegenden Situationen:

• Wenn auf der Hardwareseite eine Ausnahmesituation eintritt. Sie können beispielsweise an Ereignisse wie den Versuch einer Anwendung denken, auf eine Region außerhalb der zulässiger Adressraum (Segmentierungsfehler) oder Generieren von Maschinencode, der eine Division durch Null enthält Betrieb.
• Situationen wie die Verwendung von Tastenkombinationen wie
  instagram viewer
  Strg + C oder Strg + Z auf der Konsole durch den Benutzer, Ändern der Größe des Konsolenbildschirms oder Senden eines Kill-Signals.
• Der in der Anwendung eingestellte Timer läuft ab, das der Anwendung gegebene CPU-Limit ist hoch, die Daten kommen zu einem offenen Dateideskriptor usw.

Das Konzept von Signalen gibt es seit den frühen Versionen von Unix. Bisher gab es einige Unterschiede zwischen den Unix-Versionen bezüglich der Signalverarbeitung. Später mit die POSIX-Standardisierung gemacht für die Signalverwaltung, begannen Linux und andere Unix-Derivate, diesen Standards zu folgen. Aus diesem Grund weisen die Konzepte von Unix-Signalen und POSIX-Signalen, die Ihnen in einigen Dokumenten begegnen können, auf die Unterschiede hin.

Signalnummern

Signale haben verschiedene numerische Werte, beginnend mit eins. Beispiel: Signal 1 ist a HUP Signal in fast jedem System, oder Signal 9 ist ein TÖTEN Signal.

Es wird jedoch dringend davon abgeraten, diese Nummern zu verwenden, wenn Sie Signale in Ihren Anwendungen verwenden. Für POSIX-Signale gilt: signal.h Datei sollte sich in der Anwendung befinden und der Entwickler sollte die konstanten Definitionen verwandter Nummern verwenden, z SEUFZEND, SIGKILL, etc. stattdessen.

Untersucht man die /usr/include/signal.h Datei auf Ihrem System, können Sie die zusätzlichen Operationen und andere enthaltene Dateien sehen, indem Sie sich die Definitionen von Werten ansehen, wie z __USE_POSIX, __USE_XOPEN, __USE_POSIX199309, etc. in der Datei. Die verfügbaren Signalnummern auf Linux-Systemen finden Sie in der /usr/include/asm-generic/signal.h -Datei, die Sie nicht direkt in Ihren Anwendungscode einfügen müssen.

Signalerzeugung und Senden

Die Signalerzeugung erfolgt aufgrund eines Ereignisses. Das Senden (Ausliefern) des Signals an die betreffende Anwendung erfolgt jedoch nicht gleichzeitig mit der Erzeugung des Signals.

Damit das Signal an die Anwendung gesendet werden kann, muss die Anwendung derzeit ausgeführt werden und über CPU-Ressourcen verfügen. Daher erfolgt das Senden eines Signals an eine bestimmte Anwendung, wenn die relevante Anwendung nach dem Kontextwechsel wieder zu arbeiten beginnt.

Das Pending-Signal-Konzept

Während der Zeit von der Generierung bis zur Übertragung des Signals befinden sich die Signale in einem Bereitschaftszustand. Sie können auf die Anzahl anstehender Signale und die für einen Prozess zulässige Anzahl anstehender Signale unter zugreifen /proc/PID/status Datei.

# Für einen Prozess mit PID: 2299
cat /proc/2299/status 
# Ausgabe
...
SigQ: 2/31630
...

Signalmasken und Blockierung

Die genaue Zeit, zu der die Signale eintreffen, ist für die Anwendung oft unvorhersehbar. Daher können während eines Betriebs einige kritische Unterbrechungen auftreten. Dies kann bei einer groß angelegten Anwendung zu großen Problemen führen.

Um einige unerwünschte Situationen wie diese zu vermeiden, ist es notwendig, Signalmasken zu verwenden. Somit ist es möglich, einige Signale vor einer kritischen Operation zu blockieren. In dieser Phase ist es wichtig, den kritischen Teil abzuschließen und die definierten Blöcke zu entfernen. Auf diesen Prozess sollte der Anwendungsentwickler achten.

Wenn die Anwendung ein Signal blockiert, befinden sich andere generierte Signale des gleichen Typs in einem Wartezustand, bis die Blockierung aufgehoben wird. In der Anwendung ist auch das Senden von anstehenden Signalen vorgesehen, sobald die Sperre aufgehoben wird.

Auf diese Weise werden dieselben Arten von Signalen, die zum Zeitpunkt der Blockierung gehalten wurden, nur einmal an die Anwendung gesendet, nachdem die Blockierung im normalen Gebrauch entfernt wurde. Anders verhält es sich bei Echtzeitsignalen.

Linux-Signaltypen

Standardaktionen können je nach Signaltyp variieren. Wenn die Anwendung, die das entsprechende Signal empfängt, keine Signalhandlerfunktion hat, wird die Standardaktion ausgeführt. Manchmal bedeutet dies, die Anwendung zu beenden und manchmal das Signal zu ignorieren.

Einige Signale können nicht auf der Anwendungsschicht erfasst werden, diese Signale führen immer die Standardaktion aus (wie das KILL-Signal).

Zusätzlich zu einigen Aktionen, die zum Beenden einer Anwendung führen, wird auch eine Core-Dump-Datei erstellt. Core-Dump-Dateien, die erstellt werden, indem die virtuelle Speichertabelle des zugehörigen Prozesses auf die Festplatte geschrieben wird, helfen dabei Benutzer, um die Zustandsinformationen zu untersuchen, bevor der Prozess mit Debugging-Tools in den nächsten Phasen endet.

Die folgenden Werte basieren auf einer beispielhafte MIPS-Architektur:

Lebenszyklus von Signalen in Linux

Signale durchlaufen drei Stufen. Sie werden hauptsächlich in der Produktionsphase durch den Kernel oder einen anderen Prozess erzeugt und durch eine Zahl dargestellt. Sie arbeiten leicht und schnell, da sie keine zusätzliche Last tragen. Aber wenn Sie sich die POSIX-Seite ansehen, werden Sie sehen, dass Echtzeitsignale zusätzliche Daten übertragen können.

Nach der Produktionsphase folgt die Lieferphase für die Signale. Normalerweise erreichen Signale vom Kernel so schnell wie möglich die Anwendung. Manchmal können Anwendungen jedoch Signale blockieren, während sie kritische Vorgänge ausführen. In solchen Fällen bleibt das Signal anstehend, bis die Transaktion stattfindet.

Wie Signale sind auch Prozesse ein integraler Bestandteil des Linux-Ökosystems. Zu verstehen, was Prozesse sind und wie sie funktionieren, ist entscheidend, wenn Sie vorhaben, Linux-Systemadministrator zu werden.

Was ist ein Prozess in Linux?

Lesen Sie weiter