Linux-signalgenerering og -håndtering forklaret

Signaleringsmekanismen i Linux-kernen gør det muligt for kørende applikationer asynkront at underrette systemet, når en ny hændelse opstår. På grund af sin natur er denne signalmekanisme generelt kendt som softwareafbrydelser. Ligesom hardware afbryder, afbryder signaler en applikations normale flow, og det er uforudsigeligt, hvornår en applikation vil modtage et signal.

Lad os dykke dybt ned i signaleringsmekanismen i Linux og forstå, hvad der foregår bag kulisserne.

Grundlæggende signalkoncepter i Linux

På Linux genererer processer signaler i tre grundlæggende situationer:

• Når en ekstraordinær situation opstår på hardwaresiden. For eksempel kan du tænke på begivenheder, såsom applikationen, der forsøger at få adgang til en region uden for tilladt adresserum (segmenteringsfejl) eller generering af maskinkode, der inkluderer en division med nul operation.
• Situationer såsom brugen af ​​tastekombinationer som f.eks Ctrl + C eller Ctrl + Z på konsollen af ​​brugeren, ændre størrelsen på konsollens skærm eller sende et dræbningssignal.
instagram viewer
• Timeren indstillet i applikationen udløber, CPU-grænsen givet til applikationen er høj, dataene kommer til en åben filbeskrivelse osv.

Begrebet signaler har eksisteret siden de tidlige versioner af Unix. Tidligere var der flere forskelle mellem Unix-versioner med hensyn til signalbehandling. Senere med POSIX-standardiseringen lavet til signalhåndtering begyndte Linux og andre Unix-derivater at følge disse standarder. Af denne grund peger begreberne Unix-signaler og POSIX-signaler, som du kan støde på i nogle dokumenter, på forskellene.

Signalnumre

Signaler har forskellige numeriske værdier, startende med én. For eksempel er signal 1 a HUP signal i næsten alle systemer, eller signal 9 er en DRÆBE signal.

Det frarådes dog kraftigt at bruge disse tal, når du bruger signaler i dine applikationer. For POSIX-signaler, signal.h fil skal være i applikationen, og udvikleren skal bruge de konstante definitioner af relaterede tal som f.eks SIGHUP, SIGKILL, etc. i stedet.

Hvis du undersøger /usr/include/signal.h fil på dit system, kan du se de ekstra operationer og andre inkluderede filer ved at se på definitionerne af værdier som f.eks __USE_POSIX, __USE_XOPEN, __USE_POSIX199309, etc. i filen. Du kan finde de tilgængelige signalnumre på Linux-systemer i /usr/include/asm-generic/signal.h fil, som du ikke behøver at inkludere direkte i din ansøgningskode.

Signalgenerering og -send

Signalgenerering opstår på grund af en hændelse. Afsendelse (levering) af signalet til den relevante applikation sker dog ikke samtidig med genereringen af ​​signalet.

For at signalet kan sendes til applikationen, skal applikationen køre i øjeblikket og have CPU-ressourcer. Derfor sker afsendelsen af ​​et signal til en specifik applikation, når den relevante applikation begynder at fungere igen efter kontekstskiftet.

Det ventende signalkoncept

I tiden fra generering til transmission af signalet er signalerne i standbytilstand. Du kan få adgang til antallet af ventende signaler og antallet af ventende signaler, der er tilladt for en proces fra /proc/PID/status fil.

# For en proces med PID: 2299
kat /proc/2299/status 
# Output
...
SigQ: 2/31630
...

Signalmasker og blokering

Det nøjagtige tidspunkt, hvor signalerne vil ankomme, er ofte uforudsigeligt af applikationen. Derfor kan nogle kritiske afbrydelser forekomme under enhver operation. Dette kan give store problemer for en storstilet anvendelse.

For at forhindre nogle uønskede situationer som denne, er det nødvendigt at bruge signalmasker. Det er således muligt at blokere nogle signaler før en kritisk operation. På dette stadium er det vigtigt at færdiggøre den kritiske del og fjerne de definerede blokke. Denne proces er noget, som applikationsudvikleren bør være opmærksom på.

Når applikationen blokerer et signal, vil andre genererede signaler af samme type være i ventetilstand, indtil de ophæves. I applikationen leveres også afsendelse af ventende signaler, så snart blokeringen er fjernet.

På denne måde sendes de samme typer af signaler, der er sat på hold på tidspunktet for blokeringen, kun til applikationen én gang, efter at blokeringen er fjernet ved normal brug. Situationen er anderledes for realtidssignaler.

Linux signaltyper

Standardhandlinger kan variere afhængigt af signaltyper. Hvis applikationen, der modtager det tilsvarende signal, ikke har en signalhåndteringsfunktion, finder standardhandlingen sted. Nogle gange betyder det at afslutte applikationen og nogle gange ignorere signalet.

Nogle signaler kan ikke fanges på applikationslaget, disse signaler udfører altid standardhandlingen (såsom KILL-signalet).

Ud over nogle handlinger, der får en applikation til at afslutte, produceres der også en kernedumpfil. Core dump-filer, oprettet ved at skrive den virtuelle hukommelsestabel for den relaterede proces til disk, hjælper med bruger til at undersøge tilstandsoplysningerne, før processen slutter med fejlfindingsværktøjer i de næste trin.

Følgende værdier er baseret på en eksemplarisk MIPS-arkitektur:

Signalers livscyklus i Linux

Signaler gennemgår tre faser. De produceres primært i produktionsfasen, af kernen eller en hvilken som helst proces, og er repræsenteret ved et tal. De arbejder let og hurtigt, da de ikke har nogen ekstra belastning på sig. Men hvis du ser på POSIX-siden, vil du se, at realtidssignaler kan transmittere ekstra data.

Leveringsfasen for signalerne kommer efter produktionsfasen. Normalt når signaler applikationen fra kernen så hurtigt som muligt. Nogle gange kan applikationer dog blokere signaler, mens de udfører kritiske operationer. I sådanne tilfælde forbliver signalet afventende, indtil transaktionen finder sted.

Ligesom signaler er processer også en integreret del af Linux-økosystemet. At forstå, hvad processer er, og hvordan de fungerer, er afgørende, hvis du planlægger at blive Linux-systemadministrator.

Hvad er en proces i Linux?

Læs Næste