Semnal — Comanda Linux/Unix

Linux acceptă atât semnale fiabile POSIX (denumite în continuare „semnale standard”), cât și semnale POSIX în timp real.

Utilizarea semnalelor pe Linux

Semnalele de pe un sistem Linux spun sistem de operare cum să gestionați un program sau un proces care rulează. Când închideți un program în mod normal, acesta trimite de fapt un semnal către sistem care îi spune să închidă programul. Puteți face acest lucru și manual.

Începeți prin a căuta un proces pe care doriți să îl opriți. Puteți face acest lucru cu:

ps aux | grep -i 

Deci, dacă doriți să închideți Firefox din linia de comandă, introduceți:

ps aux | grep -i firefox

Veți obține o listă imensă de procese de la Firefox pentru că este o aplicație multithreaded. Căutați procesul de bază pentru /usr/lib/firefox. De obicei este primul.

Dacă vi se pare copleșitor, puteți utiliza și pgrep. Funcționează în mod similar, dar vă oferă doar ID-urile procesului.

pgrep firefox. 

Cel mai mic ID de proces va fi procesul de bază de care aveți nevoie.

Când îl aveți, găsiți numărul de identificare a procesului. Primul lucru enumerat va fi întotdeauna utilizatorul care execută procesul. Următorul va fi ID-ul procesului. Cu asta în mână, puteți trimite un SIGTERM semnal către proces pentru a-l opri folosind comanda ucidere.

ucide -SIGTERM 4790. 

Fiecare semnal are, de asemenea, un număr corespunzător pentru prescurtare. Numărul pentru SIGTERM este 15, astfel încât să îl puteți folosi la fel ca și cuvântul complet.

ucide -15 4790

SIGTERM este de fapt acțiunea implicită a comenzii kill. Ca rezultat, de fapt nu trebuie să-l specificați deloc. Folosește doar:

ucide 4790

Veți obține exact același rezultat.

Totul este bine dacă procesul este receptiv, dar probabil că nu veți închide un proces receptiv în acest fel, cel puțin nu pe un desktop. Deci, ce faci cu un proces care nu răspunde? Există o mulțime de semnale posibile. Pentru o idee mai bună despre cât de largă este gama, căutați-le.

ucide -l

Da, sunt multe. Din fericire, nu veți atinge marea majoritate, decât dacă începeți să dezvoltați sau să scrieți scripturi de administrare a sistemului. De cele mai multe ori, atunci când SIGTERM nu reușește să oprească un proces care nu răspunde, veți căuta echivalentul Linux al Ctrl+Alt+Delete, SIGKILL.

Spre deosebire de infamul manager de proces Ctrl+Alt+Delete, SIGKILL chiar funcționează. De fapt, este menit să ignore toți ceilalți factori și să elimine procesul ofensator, indiferent de ce. Asta înseamnă, de asemenea, că SIGKILL poate fi periculos dacă înțelegi greșit procesul.

Începeți exact în același mod, căutând ID-ul procesului.

pgrep firefox

Acum, în loc să utilizați SIGTERM pentru a opri procesul, folosiți SIGKILL, mai distructiv.

ucide -SIGKILL 4790

Chiar dacă procesul este complet blocat, ar trebui să se închidă în câteva secunde.

La fel ca în cazul SIGTERM, există un număr care corespunde lui SIGKILL. În acest caz, este 9.

ucide -9 4790

La fel ca înainte, procesul ar trebui să fie mort aproape imediat.

De asemenea, ar trebui să fii conștient SIGINT. Aceasta este o întrerupere de la tastatură și este mai multă comandă decât crezi în linia de comandă. Când apăsați Ctrl+C pentru a opri un proces dintr-o fereastră de terminal, de fapt emiteți un SIGINT. Codul său este 2, și îl puteți folosi la fel ca ceilalți cu comanda kill.

ucide -2 4790

Acest lucru nu este prea comun, deoarece este mult mai probabil să mergi cu Ctrl+C, dar e bine să fii conștient de asta.

Acestea sunt de departe cele mai comune semnale pe care le veți întâlni în utilizarea zilnică a Linux. Pentru o defalcare mai tehnică a celorlalte semnale, continuați cu secțiunea următoare.

Detaliile tehnice

Dacă sunteți administrator de sistem sau doriți să dezvoltați pentru Linux, probabil că doriți să vă aprofundați în detaliile tehnice din spatele sistemului de semnal pe Linux. Următoarea secțiune explorează defalcarea tehnică completă a semnalelor Linux. Nu aveți nevoie de aceste informații pentru a utiliza Linux pe desktop, dar dacă intenționați să explorați funcționarea interioară a sistemului, se poate dovedi neprețuit.

Semnale standard

Linux acceptă semnalele standard enumerate mai jos. Mai multe numere de semnal sunt dependente de arhitectură, așa cum este indicat în coloana „Valoare”. (Acolo unde sunt date trei valori, prima este de obicei valabilă pentru alpha și sparc, cea din mijloc pentru i386, ppc și sh, iar ultima pentru mips. A - indică faptul că un semnal este absent pe arhitectura corespunzătoare.)

Intrările din coloana „Acțiune” a tabelului specifică acțiunea implicită pentru semnal, după cum urmează:

Termen:Acțiunea implicită este de a încheia procesul.

Ign:Acțiunea implicită este ignorarea semnalului.

Miez:Acțiunea implicită este de a încheia procesul și de a descărca nucleul.

Stop:Acțiunea implicită este oprirea procesului.

În primul rând, semnalele descrise în standardul original POSIX.1.

Semnal	Valoare	Acțiune	cometariu
sau moartea procesului de control
SIGINT	2	Termen	Întrerupeți de la tastatură
SIGQUIT	3	Miez	Ieși de la tastatură
SIGILL	4	Miez	Instruire ilegală
SIGABRT	6	Miez	Semnal de anulare de la avorta(3)
SIGFPE	8	Miez	Excepție în virgulă mobilă
SIGKILL	9	Termen	Semnal de ucidere
SIGSEGV	11	Miez	Referință de memorie nevalidă
SIGPIPE	13	Termen	Broken pipe: scrieți în pipe fără cititori
SIGALRM	14	Termen	Semnal temporizator de la alarma(2)
SIGTERM	15	Termen	Semnal de terminare
SIGUSR1	30,10,16	Termen	Semnal definit de utilizator 1
SIGUSR2	31,12,17	Termen	Semnal definit de utilizator 2
SIGCHLD	20,17,18	Ign	Copil oprit sau terminat
SIGCONT	19,18,25	Continuați dacă este oprit
SIGSTOP	17,19,23	Stop	Opriți procesul
SIGTSTP	18,20,24	Stop	Opriți tastarea la tty
SIGTTIN	21,21,26	Stop	Intrare tty pentru procesul de fundal
SIGTTOU	22,22,27	Stop	ieșire tty pentru procesul de fundal

Semnalele SIGKILL și SIGSTOP nu poate fi prins, blocat sau ignorat.

Apoi semnalele nu sunt în standardul POSIX.1, ci sunt descrise în SUSv2 și SUSv3 / POSIX 1003.1-2001.

Semnal	Valoare	Acțiune	cometariu
SIGPOLL	Termen	Eveniment pollabil (Sys V). Sinonim al lui SIGIO
SIGPROF	27,27,29	Termen	Cronometrul de profilare a expirat
SIGSYS	12,-,12	Miez	Argument rău pentru rutină (SVID)
SIGTRAP	5	Miez	Capcană de urmărire/punct de întrerupere
SIGURG	16,23,21	Ign	Stare urgentă pe priză (4.2 BSD)
SIGVTALRM	26,26,28	Termen	Ceas cu alarmă virtual (4.2 BSD)
SIGXCPU	24,24,30	Miez	Limita de timp CPU a fost depășită (4,2 BSD)
SIGXFSZ	25,25,31	Miez	Limita de dimensiune a fișierului a fost depășită (4,2 BSD)

Până la Linux 2.2 inclusiv, comportamentul implicit pentru SIGSYS, SIGXCPU, SIGXFSZși (pe alte arhitecturi decât SPARC și MIPS) SIGBUS a fost de a încheia procesul (fără un dump de bază). (Pe unele alte Unice acțiunea implicită pentru SIGXCPU și SIGXFSZ este de a termina procesul fără un dump de nucleu.) Linux 2.4 se conformează cerințelor POSIX 1003.1-2001 pentru aceste semnale, terminând procesul cu un dump de nucleu.

În continuare, diverse alte semnale.

Semnal	Valoare	Acțiune	cometariu
SIGEMT	7,-,7	Termen
SIGSTKFLT	-,16,-	Termen	Eroare la stiva pe coprocesor (neutilizat)
SIGIO	23,29,22	Termen	I/O acum posibil (4.2 BSD)
SIGCLD	-,-,18	Ign	Un sinonim pentru SIGCHLD
SIGPWR	29,30,19	Termen	Pana de curent (Sistemul V)
SIGINFO	29,-,-	Un sinonim pentru SIGPWR
SIGLOST	-,-,-	Termen	Blocarea fișierului a fost pierdută
SIGWINCH	28,28,20	Ign	Semnal de redimensionare a ferestrei (4.3 BSD, Sun)
SIGUNUSED	-,31,-	Termen	Semnal neutilizat (va fi SIGSYS)

(Semnalul 29 este SIGINFO / SIGPWR pe un alfa dar SIGLOST pe un sparc.)

SIGEMT nu este specificat în POSIX 1003.1-2001, dar apare totuși pe majoritatea celorlalte Unice, unde acțiunea sa implicită este de obicei de a încheia procesul cu un dump de bază.

SIGPWR (care nu este specificat în POSIX 1003.1-2001) este de obicei ignorat în mod implicit pe acele alte Unice unde apare.

SIGIO (care nu este specificat în POSIX 1003.1-2001) este ignorat implicit pe mai multe alte Unice.

Semnale în timp real

Linux acceptă semnale în timp real așa cum au fost definite inițial în extensiile în timp real POSIX.4 (și acum incluse în POSIX 1003.1-2001). Linux acceptă 32 de semnale în timp real, numerotate de la 32 (SIGRTMIN) până la 63 (SIGRTMAX). (Programele ar trebui să se refere întotdeauna la semnale în timp real folosind notație SIGRTMIN+n, deoarece intervalul de numere de semnal în timp real variază în funcție de Unices.)

Spre deosebire de semnalele standard, semnalele în timp real nu au semnificații predefinite: întregul set de semnale în timp real poate fi utilizat în scopuri definite de aplicație. (Rețineți, totuși, că implementarea LinuxThreads utilizează primele trei semnale în timp real.)

Acțiunea implicită pentru un semnal în timp real netratat este de a termina procesul de recepție.

Semnalele în timp real se disting prin următoarele:

1. Mai multe instanțe de semnale în timp real pot fi puse în coadă. În schimb, dacă sunt livrate mai multe instanțe ale unui semnal standard în timp ce acel semnal este blocat în prezent, atunci o singură instanță este pusă în coadă.
2. Dacă semnalul este trimis folosind coadă(2), o valoare însoțitoare (fie un număr întreg, fie un pointer) poate fi trimisă împreună cu semnalul. Dacă procesul de recepție stabilește un handler pentru acest semnal folosind SA_SIGACTION steag la sigaţie(2) atunci poate obține aceste date prin intermediulsi_value domeniul siginfo_t structura transmisă ca al doilea argument către handler. În plus, cel si_pid și si_uid câmpurile acestei structuri pot fi utilizate pentru a obține PID-ul și ID-ul utilizatorului real al procesului care trimite semnalul.
3. Semnalele în timp real sunt livrate într-o comandă garantată. Mai multe semnale în timp real de același tip sunt livrate în ordinea în care au fost trimise. Dacă diferite semnale în timp real sunt trimise unui proces, acestea sunt livrate începând cu semnalul cu cel mai mic număr. (Adică, semnalele cu numere reduse au cea mai mare prioritate.)

Dacă atât semnalele standard, cât și cele în timp real sunt în așteptare pentru un proces, POSIX lasă nespecificat care este livrat primul. Linux, ca multe alte implementări, acordă prioritate semnalelor standard în acest caz.

Conform POSIX, o implementare ar trebui să permită ca cel puțin _POSIX_SIGQUEUE_MAX (32) semnale în timp real să fie puse în coadă la un proces. Cu toate acestea, în loc să pună o limită pe proces, Linux impune o limită la nivelul întregului sistem asupra numărului de semnale în timp real aflate în coadă pentru toate procesele. Această limită poate fi vizualizată (și cu privilegii) modificată prin intermediul /proc/sys/kernel/rtsig-max fişier. Un fișier înrudit,/proc/sys/kernel/rtsig-max, poate fi folosit pentru a afla câte semnale în timp real sunt în prezent în coadă.

ÎN CONFORMITATE CU.

POSIX.1.