Mecanismul de semnalizare din nucleul Linux permite aplicațiilor care rulează să notifice asincron sistemul atunci când are loc un nou eveniment. Datorită naturii sale, acest mecanism de semnalizare este cunoscut în general sub numele de întreruperi software. La fel ca întreruperile hardware, semnalele întrerup fluxul normal al unei aplicații și este imprevizibil când o aplicație va primi un semnal.

Să ne aprofundăm în mecanismul de semnalizare din Linux și să înțelegem ce se întâmplă în culise.

Concepte de bază de semnal în Linux

Pe Linux, procesele generează semnale în trei situații de bază:

  • Când apare o situație excepțională din partea hardware. De exemplu, vă puteți gândi la evenimente precum aplicația care încearcă să acceseze o regiune din afara spațiu de adrese permis (defecțiune de segmentare) sau generator de cod de mașină care include o împărțire la zero Operațiune.
  • Situații precum utilizarea combinațiilor de taste precum Ctrl + C sau Ctrl + Z pe consolă de către utilizator, redimensionarea ecranului consolei sau trimiterea unui semnal de ucidere.
  • instagram viewer
  • Temporizatorul setat în aplicație expiră, limita CPU dată aplicației este mare, datele ajung la un descriptor de fișier deschis etc.

Conceptul de semnale există încă de la primele versiuni ale Unix. Anterior, au existat mai multe diferențe între versiunile Unix în ceea ce privește procesarea semnalului. Mai târziu, cu standardizarea POSIX realizate pentru managementul semnalului, Linux și alte derivate Unix au început să urmeze aceste standarde. Din acest motiv, conceptele de semnale Unix și semnale POSIX, pe care le puteți întâlni în unele documente, indică diferențele.

Numere de semnal

Semnalele au diverse valori numerice, începând cu una. De exemplu, semnalul 1 este a HUP semnal în aproape fiecare sistem, sau semnalul 9 este a UCIDE semnal.

Cu toate acestea, utilizarea acestor numere este puternic descurajată atunci când utilizați semnale în aplicațiile dvs. Pentru semnalele POSIX, semnal.h fișierul ar trebui să fie în aplicație, iar dezvoltatorul ar trebui să utilizeze definițiile constante ale numerelor asociate, cum ar fi SUPRAȚI, SIGKILL, etc. in schimb.

Dacă examinați /usr/include/signal.h pe sistemul dvs., puteți vedea operațiunile suplimentare și alte fișiere incluse, uitându-vă la definițiile valorilor, cum ar fi __USE_POSIX, __USE_XOPEN, __USE_POSIX199309, etc. în dosar. Puteți găsi numerele de semnal disponibile pe sistemele Linux în /usr/include/asm-generic/signal.h fișier, pe care nu trebuie să îl includeți direct în codul aplicației.

Generarea și trimiterea semnalului

Generarea semnalului are loc din cauza unui eveniment. Cu toate acestea, trimiterea (livrarea) semnalului către aplicația relevantă nu are loc simultan cu generarea semnalului.

Pentru ca semnalul să fie trimis către aplicație, aplicația trebuie să ruleze în prezent și să aibă resurse CPU. Prin urmare, trimiterea unui semnal către o anumită aplicație are loc atunci când aplicația relevantă începe să funcționeze din nou după schimbarea contextului.

Conceptul de semnal în așteptare

În timpul de la generare până la transmiterea semnalului, semnalele sunt în stare de așteptare. Puteți accesa numărul de semnale în așteptare și numărul de semnale în așteptare permise pentru un proces din /proc/PID/status fişier.

# Pentru un proces cu PID: 2299
cat /proc/2299/status

# Ieșire
...
SigQ: 2/31630
...

Măști de semnalizare și blocare

Ora exactă la care vor sosi semnalele este adesea imprevizibilă de către aplicație. Prin urmare, în timpul oricărei operațiuni pot apărea unele întreruperi critice. Acest lucru poate cauza probleme majore pentru o aplicație la scară largă.

Pentru a preveni unele situații nedorite ca aceasta, este necesar să folosiți măști de semnalizare. Astfel este posibilă blocarea unor semnale înainte de o operație critică. În această etapă, este important să finalizați partea critică și să eliminați blocurile definite. Acest proces este ceva la care dezvoltatorul aplicației ar trebui să-i acorde atenție.

Când aplicația blochează un semnal, alte semnale de același tip generate vor fi în stare de așteptare până la deblocare. În aplicație, trimiterea semnalelor în așteptare este, de asemenea, prevăzută de îndată ce blocajul este eliminat.

În acest fel, aceleași tipuri de semnale puse în așteptare în momentul blocării sunt trimise aplicației o singură dată după ce blocajul este eliminat în timpul utilizării normale. Situația este diferită pentru semnalele în timp real.

Tipuri de semnal Linux

Acțiunile implicite pot varia în funcție de tipurile de semnal. Dacă aplicația care primește semnalul corespunzător nu are o funcție de gestionare a semnalului, are loc acțiunea implicită. Uneori, aceasta înseamnă închiderea aplicației și, uneori, ignorarea semnalului.

Unele semnale nu pot fi captate la nivelul aplicației, aceste semnale efectuează întotdeauna acțiunea implicită (cum ar fi semnalul KILL).

Pe lângă unele acțiuni care determină terminarea unei aplicații, este produs și un fișier de descărcare de bază. Fișierele dump de bază, create prin scrierea tabelului de memorie virtuală a procesului asociat pe disc, ajută la utilizatorul să examineze informațiile de stare înainte ca procesul să se încheie cu instrumente de depanare în etapele următoare.

Următoarele valori se bazează pe an arhitectură MIPS exemplară:

Semnal Număr Acțiune implicită Poate fi prins?
SUPRAȚI 1 Închideți cererea da
SIGINT 2 Închideți cererea da
SIGQUIT 3 Închideți aplicația (core dump) da
SIGILL 4 Închideți aplicația (core dump) da
SIGTRAP 5 Închideți aplicația (core dump) da
SIGABRT 6 Închideți aplicația (core dump) da
SIGFPE 8 Închideți aplicația (core dump) da
SIGKILL 9 Închideți cererea Nu
SIGBUS 10 Închideți aplicația (core dump) da
SIGSEGV 11 Închideți aplicația (core dump) da
SIGSYS 12 Închideți aplicația (core dump) da
SIGPIPE 13 Închideți cererea da
SIGALRM 14 Închideți cererea da
SIGTERM 15 Închideți cererea da
SIGUSR1 16 Închideți cererea da
SIGUSR2 17 Închideți cererea da
SIGCHLD 18 Ignora da
SIGTSTP 20 Stop da
SIGURG 21 Ignora da
SIGPOLL 22 Închideți cererea da
SIGSTOP 23 Stop Nu
SIGCONT 25 Continuați dacă este oprit da
SIGTTIN 26 Stop da
SIGTTOU 27 Stop da
SIGVTALRM 28 Închideți cererea da
SIGPROF 29 Închideți cererea da
SIGXCPU 30 Închideți aplicația (core dump) da
SIGXFSZ 31 Închideți aplicația (core dump) da

Ciclul de viață al semnalelor în Linux

Semnalele trec prin trei etape. Sunt produse în primul rând în faza de producție, prin miez sau orice proces și sunt reprezentate printr-un număr. Lucrează ușor și rapid, deoarece nu au nicio sarcină suplimentară asupra lor. Dar dacă te uiți la partea POSIX, vei vedea că semnalele în timp real pot transmite date suplimentare.

Faza de livrare a semnalelor vine după faza de producție. În mod normal, semnalele ajung la aplicație din nucleu cât mai repede posibil. Cu toate acestea, uneori aplicațiile pot bloca semnalele în timp ce efectuează operațiuni critice. În astfel de cazuri, semnalul rămâne în așteptare până când tranzacția are loc.

Ca și semnalele, procesele sunt, de asemenea, o parte integrantă a ecosistemului Linux. Înțelegerea proceselor și a modului în care funcționează este crucială dacă intenționați să deveniți administrator de sistem Linux.

Ce este un proces în Linux?

Citiți în continuare

AcțiuneTweetAcțiuneE-mail

Subiecte asemănătoare

  • Linux
  • Kernel Linux
  • Administrare sistem

Despre autor

Fatih Küçükkarakurt (9 articole publicate)

Un inginer și dezvoltator de software care este un fan al matematicii și al tehnologiei. Întotdeauna i-au plăcut computerele, matematica și fizica. El a dezvoltat proiecte de motoare de jocuri, precum și învățare automată, rețele neuronale artificiale și biblioteci de algebră liniară. În plus, continuă să lucreze la învățarea automată și la matrice liniare.

Mai multe de la Fatih Küçükkarakurt

Aboneaza-te la newsletter-ul nostru

Alăturați-vă buletinului nostru informativ pentru sfaturi tehnice, recenzii, cărți electronice gratuite și oferte exclusive!

Click aici pentru a te abona