Linux-signaalgeneratie en -verwerking uitgelegd

Dankzij het signaleringsmechanisme in de Linux-kernel kunnen draaiende applicaties het systeem asynchroon op de hoogte stellen wanneer zich een nieuwe gebeurtenis voordoet. Vanwege zijn aard staat dit signaleringsmechanisme algemeen bekend als software-interrupts. Net als hardware-interrupts, onderbreken signalen de normale stroom van een applicatie, en het is onvoorspelbaar wanneer een applicatie een signaal ontvangt.

Laten we diep in het signaleringsmechanisme in Linux duiken en begrijpen wat er achter de schermen gebeurt.

Basissignaalconcepten in Linux

Op Linux genereren processen signalen in drie basissituaties:

• Wanneer zich aan de hardwarekant een uitzonderlijke situatie voordoet. U kunt bijvoorbeeld denken aan gebeurtenissen zoals de toepassing die probeert toegang te krijgen tot een regio buiten de toegestane adresruimte (segmentatiefout) of het genereren van machinecode die een deling door nul bevat operatie.
• Situaties zoals het gebruik van toetscombinaties zoals Ctrl + C of Ctrl + Z
  instagram viewer
  op de console door de gebruiker, het formaat van het consolescherm wijzigen of een kill-signaal verzenden.
• De timer die in de applicatie is ingesteld, loopt af, de CPU-limiet die aan de applicatie wordt gegeven, is hoog, de gegevens komen naar een open bestandsdescriptor, enz.

Het concept van signalen bestaat al sinds de vroege versies van Unix. Voorheen waren er verschillende verschillen tussen Unix-versies met betrekking tot signaalverwerking. Later, met de POSIX-standaardisatie gemaakt voor signaalbeheer, begonnen Linux en andere Unix-derivaten deze standaarden te volgen. Om deze reden wijzen de concepten van Unix-signalen en POSIX-signalen, die u in sommige documenten kunt tegenkomen, op de verschillen.

Signaalnummers

Signalen hebben verschillende numerieke waarden, te beginnen met één. Signaal 1 is bijvoorbeeld a HUP signaal in bijna elk systeem, of signaal 9 is a DODEN signaal.

Het gebruik van deze nummers wordt echter sterk afgeraden wanneer u signalen in uw toepassingen gebruikt. Voor POSIX-signalen, signaal.h bestand moet in de applicatie zijn en de ontwikkelaar moet de constante definities van gerelateerde nummers gebruiken, zoals: SIGHUP, SIGKILL, enz. in plaats van.

Als je de /usr/include/signal.h bestand op uw systeem, kunt u de extra bewerkingen en andere opgenomen bestanden zien door te kijken naar de definities van waarden zoals: __USE_POSIX, __USE_XOPEN, __USE_POSIX199309, enz. in het bestand. U vindt de beschikbare signaalnummers op Linux-systemen in de /usr/include/asm-generic/signal.h bestand, dat u niet rechtstreeks in uw toepassingscode hoeft op te nemen.

Signaal genereren en verzenden

Signaalgeneratie vindt plaats als gevolg van een gebeurtenis. Het verzenden (afgeven) van het signaal naar de betreffende applicatie vindt echter niet gelijktijdig plaats met het genereren van het signaal.

Om het signaal naar de applicatie te sturen, moet de applicatie momenteel actief zijn en CPU-bronnen hebben. Het verzenden van een signaal naar een specifieke applicatie vindt dus plaats wanneer de betreffende applicatie weer gaat werken na de contextwisseling.

Het hangende signaalconcept

Gedurende de tijd van het genereren tot het verzenden van het signaal bevinden de signalen zich in een standby-toestand. U kunt toegang krijgen tot het aantal wachtende signalen en het aantal wachtende signalen dat is toegestaan ​​voor een proces vanuit de /proc/PID/status het dossier.

# Voor een proces met PID: 2299
cat /proc/2299/status 
# Uitgang
...
SigQ: 2/31630
...

Signaalmaskers en blokkering

Het exacte tijdstip waarop de signalen zullen aankomen is vaak onvoorspelbaar door de applicatie. Daarom kunnen er tijdens elke bewerking enkele kritieke onderbrekingen optreden. Dit kan voor een grootschalige toepassing grote problemen opleveren.

Om dit soort ongewenste situaties te voorkomen, is het noodzakelijk om signaalmaskers te gebruiken. Zo is het mogelijk om enkele signalen te blokkeren voor een kritische operatie. In dit stadium is het belangrijk om het kritieke deel te voltooien en de gedefinieerde blokken te verwijderen. Dit proces is iets waar de applicatieontwikkelaar op moet letten.

Wanneer de applicatie een signaal blokkeert, zullen andere gegenereerde signalen van hetzelfde type in een wachttoestand zijn totdat de blokkering wordt opgeheven. In de applicatie wordt ook voorzien in het verzenden van hangende signalen zodra de blokkering wordt verwijderd.

Op deze manier worden dezelfde typen signalen die op het moment van de blokkering in de wacht zijn gezet, slechts één keer naar de applicatie verzonden nadat de blokkering bij normaal gebruik is verwijderd. De situatie is anders voor realtime signalen.

Linux-signaaltypen

Standaardacties kunnen per signaaltype verschillen. Als de applicatie die het bijbehorende signaal ontvangt geen signaalverwerkingsfunctie heeft, vindt de standaardactie plaats. Soms betekent dit het beëindigen van de applicatie en soms het negeren van het signaal.

Sommige signalen kunnen niet worden opgevangen op de applicatielaag, deze signalen voeren altijd de standaardactie uit (zoals het KILL-signaal).

Naast enkele acties die ervoor zorgen dat een toepassing wordt beëindigd, wordt er ook een kerndumpbestand geproduceerd. Core dump-bestanden, gemaakt door de virtuele geheugentabel van het gerelateerde proces naar schijf te schrijven, helpen de gebruiker om de statusinformatie te onderzoeken voordat het proces eindigt met foutopsporingstools in de volgende fasen.

De volgende waarden zijn gebaseerd op een voorbeeldige MIPS-architectuur:

Levenscyclus van signalen in Linux

Signalen doorlopen drie fasen. Ze worden voornamelijk geproduceerd in de productiefase, door de pit of een ander proces, en worden weergegeven door een nummer. Ze werken licht en snel, omdat ze niet extra belast worden. Maar als je naar de POSIX-kant kijkt, zie je dat realtime signalen extra data kunnen verzenden.

De leveringsfase voor de signalen komt na de productiefase. Normaal gesproken bereiken signalen de applicatie zo snel mogelijk vanuit de kernel. Soms kunnen toepassingen echter signalen blokkeren tijdens het uitvoeren van kritieke bewerkingen. In dergelijke gevallen blijft het signaal in afwachting totdat de transactie plaatsvindt.

Net als signalen zijn processen ook een integraal onderdeel van het Linux-ecosysteem. Begrijpen wat processen zijn en hoe ze werken, is cruciaal als je van plan bent om Linux-systeembeheerder te worden.

Wat is een proces in Linux?

Lees volgende