Linux-signalgenerering og -håndtering forklart

Signaleringsmekanismen i Linux-kjernen lar kjørende applikasjoner asynkront varsle systemet når en ny hendelse oppstår. På grunn av sin natur er denne signalmekanismen generelt kjent som programvareavbrudd. Akkurat som maskinvareavbrudd, avbryter signaler en applikasjons normale flyt, og det er uforutsigbart når en applikasjon vil motta et signal.

La oss dykke dypt inn i signalmekanismen i Linux og forstå hva som foregår bak kulissene.

Grunnleggende signalkonsepter i Linux

På Linux genererer prosesser signaler i tre grunnleggende situasjoner:

• Når en eksepsjonell situasjon oppstår på maskinvaresiden. Du kan for eksempel tenke på hendelser som at applikasjonen prøver å få tilgang til en region utenfor tillatt adresserom (segmenteringsfeil) eller generering av maskinkode som inkluderer en divisjon med null operasjon.
• Situasjoner som bruk av tastekombinasjoner som Ctrl + C eller Ctrl + Z på konsollen av brukeren, endre størrelse på konsollskjermen eller sende et drepesignal.
• Tidtakeren som er angitt i applikasjonen utløper, CPU-grensen gitt til applikasjonen er høy, dataene kommer til en åpen filbeskrivelse, etc.
  instagram viewer

Konseptet med signaler har eksistert siden de tidlige versjonene av Unix. Tidligere var det flere forskjeller mellom Unix-versjoner angående signalbehandling. Senere, med POSIX-standardiseringen laget for signalhåndtering begynte Linux og andre Unix-derivater å følge disse standardene. Av denne grunn peker konseptene Unix-signaler og POSIX-signaler, som du kan støte på i enkelte dokumenter, på forskjellene.

Signalnummer

Signaler har forskjellige numeriske verdier, som starter med én. For eksempel er signal 1 a HUP signal i nesten alle systemer, eller signal 9 er en DREPE signal.

Imidlertid frarådes det sterkt å bruke disse tallene når du bruker signaler i applikasjonene dine. For POSIX-signaler, signal.h filen skal være i applikasjonen og utvikleren bør bruke konstante definisjoner av relaterte tall som f.eks SIGHUP, SIGKILL, etc. i stedet.

Hvis du undersøker /usr/include/signal.h fil på systemet ditt, kan du se tilleggsoperasjonene og andre inkluderte filer ved å se på definisjonene av verdier som __USE_POSIX, __USE_XOPEN, __USE_POSIX199309, etc. i filen. Du kan finne tilgjengelige signalnumre på Linux-systemer i /usr/include/asm-generic/signal.h fil, som du ikke trenger å inkludere direkte i søknadskoden.

Signalgenerering og -sending

Signalgenerering oppstår på grunn av en hendelse. Sending (levering) av signalet til den aktuelle applikasjonen skjer imidlertid ikke samtidig med genereringen av signalet.

For at signalet skal sendes til applikasjonen, må applikasjonen kjøres og ha CPU-ressurser. Derfor skjer sendingen av et signal til en spesifikk applikasjon når den relevante applikasjonen begynner å fungere igjen etter kontekstbyttet.

Det ventende signalkonseptet

I løpet av tiden fra generering til overføring av signalet er signalene i standby-tilstand. Du kan få tilgang til antall ventende signaler og antall ventende signaler som er tillatt for en prosess fra /proc/PID/status fil.

# For en prosess med PID: 2299
cat /proc/2299/status 
# Utgang
...
SigQ: 2/31630
...

Signalmasker og blokkering

Den nøyaktige tiden signalene vil ankomme er ofte uforutsigbar av applikasjonen. Derfor kan noen kritiske avbrudd oppstå under enhver operasjon. Dette kan skape store problemer for en storskala applikasjon.

For å forhindre noen uønskede situasjoner som dette, er det nødvendig å bruke signalmasker. Dermed er det mulig å blokkere noen signaler før en kritisk operasjon. På dette stadiet er det viktig å fullføre den kritiske delen og fjerne de definerte blokkene. Denne prosessen er noe applikasjonsutvikleren bør være oppmerksom på.

Når applikasjonen blokkerer et signal, vil andre signaler av samme type som genereres, være i ventetilstand til de deaktiveres. I applikasjonen er det også gitt sending av ventende signaler så snart blokkeringen er fjernet.

På denne måten sendes de samme typene signaler som er satt på vent ved blokkeringstidspunktet til applikasjonen kun én gang etter at blokkeringen er fjernet ved normal bruk. Situasjonen er annerledes for sanntidssignaler.

Linux-signaltyper

Standardhandlinger kan variere avhengig av signaltyper. Hvis applikasjonen som mottar det tilsvarende signalet ikke har en signalbehandlerfunksjon, finner standardhandlingen sted. Noen ganger betyr dette å avslutte applikasjonen og noen ganger ignorere signalet.

Noen signaler kan ikke fanges opp på applikasjonslaget, disse signalene utfører alltid standardhandlingen (som KILL-signalet).

I tillegg til noen handlinger som får en applikasjon til å avslutte, produseres det også en kjernedumpfil. Kjernedumpfiler, opprettet ved å skrive den virtuelle minnetabellen for den relaterte prosessen til disk, hjelper bruker å undersøke tilstandsinformasjonen før prosessen avsluttes med feilsøkingsverktøy i de neste stadiene.

Følgende verdier er basert på en eksemplarisk MIPS-arkitektur:

Livssyklus av signaler i Linux

Signalene går gjennom tre stadier. De produseres primært i produksjonsfasen, av kjernen eller en hvilken som helst prosess, og er representert med et tall. De jobber lett og raskt, da de ikke har noen ekstra belastning på seg. Men hvis du ser på POSIX-siden, vil du se at sanntidssignaler kan overføre ekstra data.

Leveringsfasen for signalene kommer etter produksjonsfasen. Normalt når signaler applikasjonen fra kjernen så raskt som mulig. Noen ganger kan imidlertid applikasjoner blokkere signaler mens de utfører kritiske operasjoner. I slike tilfeller forblir signalet ventende til transaksjonen finner sted.

I likhet med signaler er også prosesser en integrert del av Linux-økosystemet. Å forstå hva prosesser er og hvordan de fungerer er avgjørende hvis du planlegger å bli Linux-systemadministrator.

Hva er en prosess i Linux?

Les Neste