Il meccanismo di segnalazione nel kernel Linux consente alle applicazioni in esecuzione di notificare in modo asincrono il sistema quando si verifica un nuovo evento. Per sua natura, questo meccanismo di segnalazione è generalmente noto come interrupt software. Proprio come gli interrupt hardware, i segnali interrompono il normale flusso di un'applicazione ed è imprevedibile quando un'applicazione riceverà un segnale.
Immergiamoci nel meccanismo di segnalazione in Linux e capiamo cosa succede dietro le quinte.
Concetti di base sui segnali in Linux
Su Linux, i processi generano segnali in tre situazioni di base:
- Quando si verifica una situazione eccezionale lato hardware. Ad esempio, puoi pensare a eventi come l'applicazione che tenta di accedere a una regione al di fuori del spazio di indirizzi consentito (errore di segmentazione) o generazione di codice macchina che include una divisione per zero operazione.
- Situazioni come l'uso di combinazioni di tasti come CTRL+C o CTRL+Z sulla console dall'utente, ridimensionando lo schermo della console o inviando un kill signal.
- Il timer impostato nell'applicazione scade, il limite di CPU assegnato all'applicazione è alto, i dati arrivano a un descrittore di file aperto, ecc.
Il concetto di segnali esiste sin dalle prime versioni di Unix. In precedenza, c'erano diverse differenze tra le versioni Unix per quanto riguarda l'elaborazione del segnale. Più tardi, con la standardizzazione POSIX realizzato per la gestione del segnale, Linux e altri derivati di Unix hanno iniziato a seguire questi standard. Per questo motivo, i concetti di segnali Unix e segnali POSIX, che potresti incontrare in alcuni documenti, indicano le differenze.
Numeri di segnale
I segnali hanno vari valori numerici, a partire da uno. Ad esempio, il segnale 1 è a HUP segnale in quasi tutti i sistemi, oppure il segnale 9 è a UCCISIONE segnale.
Tuttavia, l'utilizzo di questi numeri è fortemente sconsigliato quando si utilizzano i segnali nelle applicazioni. Per i segnali POSIX, segnale.h il file dovrebbe essere nell'applicazione e lo sviluppatore dovrebbe utilizzare le definizioni costanti di numeri correlati come SIGILLO, SIGKILL, eccetera. invece.
Se esamini il /usr/include/signal.h sul tuo sistema, puoi vedere le operazioni aggiuntive e altri file inclusi osservando le definizioni di valori come __USE_POSIX, __USE_XOPEN, __USE_POSIX199309, eccetera. nel file. Puoi trovare i numeri di segnale disponibili sui sistemi Linux in /usr/include/asm-generic/signal.h file, che non è necessario includere direttamente nel codice dell'applicazione.
Generazione e invio di segnali
La generazione del segnale si verifica a causa di un evento. Tuttavia, l'invio (consegna) del segnale all'applicazione pertinente non avviene contemporaneamente alla generazione del segnale.
Affinché il segnale venga inviato all'applicazione, l'applicazione deve essere attualmente in esecuzione e disporre di risorse CPU. Pertanto, l'invio di un segnale a un'applicazione specifica si verifica quando l'applicazione in questione riprende a funzionare dopo il cambio di contesto.
Il concetto di segnale in sospeso
Durante il tempo dalla generazione alla trasmissione del segnale, i segnali sono in uno stato di attesa. È possibile accedere al numero di segnali in sospeso e al numero di segnali in sospeso consentiti per un processo dal /proc/PID/status file.
# Per un processo con PID: 2299
cat /proc/2299/status
# Produzione
...
SigQ: 2/31630
...
Maschere di segnalazione e blocco
L'ora esatta in cui arriveranno i segnali è spesso imprevedibile dall'applicazione. Pertanto, durante qualsiasi operazione possono verificarsi alcune interruzioni critiche. Ciò può causare gravi problemi per un'applicazione su larga scala.
Per prevenire alcune situazioni indesiderate come questa, è necessario utilizzare maschere di segnalazione. In questo modo è possibile bloccare alcuni segnali prima di un'operazione critica. In questa fase è importante completare la parte critica e rimuovere i blocchi definiti. Questo processo è qualcosa a cui lo sviluppatore dell'applicazione dovrebbe prestare attenzione.
Quando l'applicazione blocca un segnale, altri segnali dello stesso tipo generati saranno in attesa fino allo sblocco. Nell'applicazione è previsto anche l'invio dei segnali pendenti non appena il blocco viene rimosso.
In questo modo, gli stessi tipi di segnali posti in attesa al momento del blocco vengono inviati all'applicazione solo una volta dopo che il blocco è stato rimosso durante il normale utilizzo. La situazione è diversa per i segnali in tempo reale.
Tipi di segnali Linux
Le azioni predefinite possono variare in base ai tipi di segnale. Se l'applicazione che riceve il segnale corrispondente non dispone di una funzione di gestione del segnale, viene eseguita l'azione predefinita. A volte questo significa terminare l'applicazione e talvolta ignorare il segnale.
Alcuni segnali non possono essere acquisiti a livello di applicazione, questi segnali eseguono sempre l'azione predefinita (come il segnale KILL).
Oltre ad alcune azioni che causano la chiusura di un'applicazione, viene prodotto anche un file di dump principale. I file di dump principali, creati scrivendo la tabella di memoria virtuale del processo correlato su disco, aiutano il utente per esaminare le informazioni sullo stato prima che il processo termini con gli strumenti di debug nelle fasi successive.
I seguenti valori si basano su un architettura MIPS esemplare:
Segnale | Numero | Azione predefinita | Può essere catturato? |
---|---|---|---|
SIGILLO | 1 | Termina l'applicazione | sì |
SIGINT | 2 | Termina l'applicazione | sì |
SIGQUIT | 3 | Termina l'applicazione (core dump) | sì |
SIGILL | 4 | Termina l'applicazione (core dump) | sì |
SIGTRAPPOLA | 5 | Termina l'applicazione (core dump) | sì |
SIGABRT | 6 | Termina l'applicazione (core dump) | sì |
SIGFPE | 8 | Termina l'applicazione (core dump) | sì |
SIGKILL | 9 | Termina l'applicazione | No |
SIGBUS | 10 | Termina l'applicazione (core dump) | sì |
SIGSEGV | 11 | Termina l'applicazione (core dump) | sì |
SIGSYS | 12 | Termina l'applicazione (core dump) | sì |
SIGPIPE | 13 | Termina l'applicazione | sì |
SIGALRM | 14 | Termina l'applicazione | sì |
SIGTERM | 15 | Termina l'applicazione | sì |
SIGUSR1 | 16 | Termina l'applicazione | sì |
SIGUSR2 | 17 | Termina l'applicazione | sì |
SIGCHLD | 18 | Ignorare | sì |
SIGTSTP | 20 | Fermare | sì |
SIGURG | 21 | Ignorare | sì |
SIGPOL | 22 | Termina l'applicazione | sì |
SIGSTOP | 23 | Fermare | No |
SIGCONT | 25 | Continua se interrotto | sì |
SIGTTIN | 26 | Fermare | sì |
SIGTTOU | 27 | Fermare | sì |
SIGVTALRM | 28 | Termina l'applicazione | sì |
SIGPROF | 29 | Termina l'applicazione | sì |
CPU SIGX | 30 | Termina l'applicazione (core dump) | sì |
SIGXFSZ | 31 | Termina l'applicazione (core dump) | sì |
Ciclo di vita dei segnali in Linux
I segnali passano attraverso tre fasi. Sono prodotti principalmente nella fase di produzione, dal nocciolo o da qualsiasi processo, e sono rappresentati da un numero. Funzionano in modo leggero e rapido, poiché non hanno alcun carico aggiuntivo su di loro. Ma se guardi il lato POSIX, vedrai che i segnali in tempo reale possono trasmettere dati extra.
La fase di erogazione dei segnali avviene dopo la fase di produzione. Normalmente, i segnali raggiungono l'applicazione dal kernel il più rapidamente possibile. Tuttavia, a volte le applicazioni possono bloccare i segnali durante l'esecuzione di operazioni critiche. In tali casi, il segnale rimane sospeso fino a quando la transazione non ha luogo.
Come i segnali, anche i processi sono parte integrante dell'ecosistema Linux. Capire cosa sono i processi e come funzionano è fondamentale se hai intenzione di diventare un amministratore di sistema Linux.
Che cos'è un processo in Linux?
Leggi Avanti
Argomenti correlati
- Linux
- kernel Linux
- Amministrazione di sistema
Circa l'autore

Un ingegnere e sviluppatore di software che è un fan della matematica e della tecnologia. Gli sono sempre piaciuti i computer, la matematica e la fisica. Ha sviluppato progetti di motori di gioco, machine learning, reti neurali artificiali e librerie di algebra lineare. Inoltre continua a lavorare su machine learning e matrici lineari.
Iscriviti alla nostra Newsletter
Iscriviti alla nostra newsletter per suggerimenti tecnici, recensioni, ebook gratuiti e offerte esclusive!
Clicca qui per iscriverti