Linux-signalgenerering och -hantering förklaras

Signaleringsmekanismen i Linux-kärnan tillåter körande applikationer att asynkront meddela systemet när en ny händelse inträffar. På grund av sin natur är denna signalmekanism allmänt känd som mjukvaruavbrott. Precis som hårdvaruavbrott avbryter signaler ett programs normala flöde, och det är oförutsägbart när ett program kommer att ta emot en signal.

Låt oss dyka djupt in i signalmekanismen i Linux och förstå vad som händer bakom kulisserna.

Grundläggande signalkoncept i Linux

På Linux genererar processer signaler i tre grundläggande situationer:

• När en exceptionell situation inträffar på hårdvarusidan. Till exempel kan du tänka på händelser som att applikationen försöker komma åt en region utanför tillåtet adressutrymme (segmenteringsfel) eller generering av maskinkod som inkluderar en division med noll drift.
• Situationer som användningen av tangentkombinationer som Ctrl + C eller Ctrl + Z på konsolen av användaren, ändra storlek på konsolskärmen eller skicka en dödsignal.
• Timern som är inställd i applikationen går ut, CPU-gränsen som ges till applikationen är hög, data kommer till en öppen filbeskrivning, etc.
  instagram viewer

Konceptet med signaler har funnits sedan de tidiga versionerna av Unix. Tidigare fanns det flera skillnader mellan Unix-versioner när det gäller signalbehandling. Senare med POSIX-standardiseringen gjorda för signalhantering började Linux och andra Unix-derivat följa dessa standarder. Av denna anledning pekar koncepten Unix-signaler och POSIX-signaler, som du kan stöta på i vissa dokument, på skillnaderna.

Signalnummer

Signaler har olika numeriska värden, som börjar med ett. Till exempel är signal 1 a HUP signal i nästan alla system, eller signal 9 är en DÖDA signal.

Att använda dessa siffror avråds dock starkt när du använder signaler i dina applikationer. För POSIX-signaler, signal.h filen ska finnas i applikationen och utvecklaren ska använda de konstanta definitionerna av relaterade nummer som t.ex SIGHUP, SIGKILL, etc. istället.

Om du undersöker /usr/include/signal.h fil på ditt system kan du se ytterligare operationer och andra inkluderade filer genom att titta på definitionerna av värden som t.ex __USE_POSIX, __USE_XOPEN, __USE_POSIX199309, etc. i filen. Du kan hitta de tillgängliga signalnumren på Linux-system i /usr/include/asm-generic/signal.h fil, som du inte behöver inkludera direkt i din ansökningskod.

Signalgenerering och sändning

Signalgenerering uppstår på grund av en händelse. Att skicka (leverera) signalen till den relevanta applikationen sker dock inte samtidigt med genereringen av signalen.

För att signalen ska skickas till applikationen måste applikationen vara igång och ha CPU-resurser. Därför sker sändningen av en signal till en specifik applikation när den relevanta applikationen börjar fungera igen efter kontextväxlingen.

Det väntande signalkonceptet

Under tiden från generering till sändning av signalen är signalerna i standby-läge. Du kan komma åt antalet väntande signaler och antalet väntande signaler som tillåts för en process från /proc/PID/status fil.

# För en process med PID: 2299
cat /proc/2299/status 
# Utgång
...
SigQ: 2/31630
...

Signalmasker och blockering

Den exakta tiden signalerna kommer fram är ofta oförutsägbar av applikationen. Därför kan vissa kritiska avbrott inträffa under alla operationer. Detta kan orsaka stora problem för en storskalig tillämpning.

För att förhindra vissa oönskade situationer som denna är det nödvändigt att använda signalmasker. Det är således möjligt att blockera vissa signaler före en kritisk operation. I detta skede är det viktigt att slutföra den kritiska delen och ta bort de definierade blocken. Denna process är något som applikationsutvecklaren bör vara uppmärksam på.

När applikationen blockerar en signal kommer andra signaler av samma typ som genereras att vara i ett vänteläge tills de avblockeras. I applikationen tillhandahålls också sändning av väntande signaler så snart blockeringen tas bort.

På detta sätt skickas samma typer av signaler som lagts på is vid tidpunkten för blockeringen till applikationen endast en gång efter att blocket tagits bort vid normal användning. Situationen är annorlunda för realtidssignaler.

Linux-signaltyper

Standardåtgärder kan variera beroende på signaltyp. Om applikationen som tar emot motsvarande signal inte har en signalhanterarfunktion, sker standardåtgärden. Ibland innebär detta att man avslutar applikationen och ibland ignorerar signalen.

Vissa signaler kan inte fångas i applikationslagret, dessa signaler utför alltid standardåtgärden (som KILL-signalen).

Förutom några åtgärder som gör att ett program avslutas, produceras också en kärndumpfil. Kärndumpfiler, skapade genom att skriva den virtuella minnestabellen för den relaterade processen till disk, hjälper till användaren att undersöka tillståndsinformationen innan processen avslutas med felsökningsverktyg i nästa steg.

Följande värden är baserade på en exemplarisk MIPS-arkitektur:

Signalernas livscykel i Linux

Signaler går igenom tre steg. De produceras främst i produktionsfasen, av kärnan eller vilken process som helst, och representeras av ett nummer. De arbetar lätt och snabbt, eftersom de inte har någon extra belastning på sig. Men om du tittar på POSIX-sidan ser du att realtidssignaler kan överföra extra data.

Leveransfasen för signalerna kommer efter produktionsfasen. Normalt når signaler applikationen från kärnan så snabbt som möjligt. Men ibland kan applikationer blockera signaler när de utför kritiska operationer. I sådana fall förblir signalen vilande tills transaktionen äger rum.

Liksom signaler är processer också en integrerad del av Linux-ekosystemet. Att förstå vad processer är och hur de fungerar är avgörande om du planerar att bli Linux-systemadministratör.

Vad är en process i Linux?

Läs Nästa