Objašnjeno generiranje i rukovanje Linux signalom

Mehanizam signalizacije u jezgri Linuxa omogućuje pokrenutim aplikacijama da asinkrono obavijeste sustav kada se dogodi novi događaj. Zbog svoje prirode, ovaj mehanizam signalizacije općenito je poznat kao softverski prekidi. Baš kao hardverski prekidi, signali prekidaju normalan tijek aplikacije i nepredvidivo je kada će aplikacija primiti signal.

Zaronimo duboko u mehanizam signalizacije u Linuxu i shvatimo što se događa iza kulisa.

Osnovni koncepti signala u Linuxu

Na Linuxu procesi generiraju signale u tri osnovne situacije:

• Kada se dogodi iznimna situacija na hardverskoj strani. Na primjer, možete razmišljati o događajima kao što je aplikacija koja pokušava pristupiti regiji izvan dopušteni adresni prostor (greška segmentacije) ili generiranje strojnog koda koji uključuje podjelu nulom operacija.
• Situacije poput korištenja kombinacija tipki poput Ctrl + C ili Ctrl + Z na konzoli od strane korisnika, mijenjanje veličine zaslona konzole ili slanje signala za ukidanje.
• Tajmer postavljen u aplikaciji istječe, CPU ograničenje dano aplikaciji je visoko, podaci dolaze u otvoreni deskriptor datoteke itd.
  instagram viewer

Koncept signala postoji još od ranih verzija Unixa. Prije je postojalo nekoliko razlika između verzija Unixa u pogledu obrade signala. Kasnije, sa standardizacija POSIX napravljen za upravljanje signalima, Linux i drugi derivati ​​Unixa počeli su slijediti ove standarde. Iz tog razloga koncepti Unix signala i POSIX signala, koje možete susresti u nekim dokumentima, ukazuju na razlike.

Signalni brojevi

Signali imaju različite numeričke vrijednosti, počevši od jedne. Na primjer, signal 1 je a HUP signal u gotovo svakom sustavu, ili signal 9 je a UBITI signal.

Međutim, upotreba ovih brojeva se ne preporučuje kada koristite signale u svojim aplikacijama. Za POSIX signale, signal.h datoteka bi trebala biti u aplikaciji, a programer bi trebao koristiti stalne definicije povezanih brojeva kao što su UZDIHANJE, SIGKILL, itd. umjesto toga.

Ako pregledate /usr/include/signal.h datoteku na vašem sustavu, možete vidjeti dodatne operacije i druge uključene datoteke gledajući definicije vrijednosti kao što su __USE_POSIX, __USE_XOPEN, __USE_POSIX199309, itd. u datoteci. Dostupne brojeve signala na Linux sustavima možete pronaći u /usr/include/asm-generic/signal.h datoteku, koju ne morate uključiti izravno u kôd aplikacije.

Generiranje i slanje signala

Generiranje signala nastaje zbog događaja. Međutim, slanje (isporuka) signala relevantnoj aplikaciji ne događa se istovremeno s generiranjem signala.

Da bi se signal poslao aplikaciji, aplikacija mora biti trenutno pokrenuta i imati CPU resurse. Stoga se slanje signala određenoj aplikaciji događa kada relevantna aplikacija ponovno počne raditi nakon promjene konteksta.

Koncept signala na čekanju

Tijekom vremena od generiranja do prijenosa signala, signali su u stanju pripravnosti. Možete pristupiti broju signala na čekanju i broju signala na čekanju dopuštenih za proces iz /proc/PID/status datoteka.

# Za proces s PID-om: 2299
mačka /proc/2299/status 
# Izlaz
...
SigQ: 2/31630
...

Signalne maske i blokiranje

Aplikacija često ne može predvidjeti točno vrijeme kada će signali stići. Stoga se tijekom bilo koje operacije mogu pojaviti neki kritični prekidi. To može uzrokovati velike probleme za primjenu velikih razmjera.

Kako bi se spriječile ovakve nepoželjne situacije, potrebno je koristiti signalne maske. Tako je moguće blokirati neke signale prije kritične operacije. U ovoj fazi važno je dovršiti kritični dio i ukloniti definirane blokove. Ovaj proces je nešto na što bi programer aplikacije trebao obratiti pažnju.

Kada aplikacija blokira signal, drugi generirani signali iste vrste bit će u stanju čekanja dok se ne deblokiraju. U aplikaciji je također omogućeno slanje signala na čekanju čim se blok ukloni.

Na taj način, iste vrste signala stavljenih na čekanje u vrijeme blokade šalju se aplikaciji samo jednom nakon što se blok ukloni u normalnoj upotrebi. Situacija je drugačija za signale u stvarnom vremenu.

Vrste signala za Linux

Zadane radnje mogu se razlikovati ovisno o vrsti signala. Ako aplikacija koja prima odgovarajući signal nema funkciju rukovanja signalom, izvršava se zadana radnja. Ponekad to znači prekid aplikacije, a ponekad ignoriranje signala.

Neki signali se ne mogu uhvatiti na aplikacijskom sloju, ti signali uvijek izvode zadanu radnju (kao što je KILL signal).

Uz neke radnje koje uzrokuju prekid aplikacije, također se proizvodi datoteka s ispisom jezgre. Core dump datoteke, stvorene pisanjem tablice virtualne memorije povezanog procesa na disk, pomažu korisnik da ispita informacije o stanju prije nego što proces završi s alatima za otklanjanje pogrešaka u sljedećim fazama.

Sljedeće vrijednosti temelje se na an uzorna MIPS arhitektura:

Životni ciklus signala u Linuxu

Signali prolaze kroz tri faze. Proizvode se prvenstveno u fazi proizvodnje, jezgrom ili bilo kojim procesom, a predstavljeni su brojem. Djeluju lagano i brzo, jer nemaju dodatno opterećenje. Ali ako pogledate POSIX stranu, vidjet ćete da signali u stvarnom vremenu mogu prenositi dodatne podatke.

Faza isporuke za signale dolazi nakon faze proizvodnje. Obično signali iz kernela stignu do aplikacije što je brže moguće. Međutim, ponekad aplikacije mogu blokirati signale dok obavljaju kritične operacije. U takvim slučajevima signal ostaje na čekanju dok se transakcija ne izvrši.

Kao i signali, procesi su također sastavni dio Linux ekosustava. Razumijevanje što su procesi i kako rade ključno je ako planirate postati administrator sustava Linux.

Što je proces u Linuxu?

Pročitajte dalje