signal.tex

   1 \chapter{I segnali}
   2 \label{sec:signals}
   3
   4 I segnali sono il primo e più semplice meccanismo di comunicazione nei
   5 confronti dei processi. Non portano con se nessuna informazione che non sia il
   6 loro tipo, si tratta in sostanza di un'interruzione software portata ad un
   7 processo.
   8
   9 In genere i segnali vengono usati dal kernel per riportare situazioni
  10 eccezionali (come errori di accesso, eccezioni aritmetiche, etc.) ma possono
  11 anche essere usati come forma elementare di comunicazione fra processi (ad
  12 esempio vengono usati per il controllo di sessione), per notificare eventi
  13 (come la terminazione di un processo figlio), etc.
  14
  15 \section{I concetti base}
  16 \label{sec:sig_base}
  17
  18 Come il nome stesso indica i segnali sono usati per notificare ad un processo
  19 l'occorrenza di un evento eccezionale. Gli eventi che possono generare un
  20 segnale sono vari; un breve elenco di possibile cause è il seguente:
  21
  22 \begin{itemize}
  23 \item un errore del programma, come una divisione per zero o un tentativo di
  24   accesso alla memoria fuori dai limiti validi.
  25 \item la terminazione di un processo figlio.
  26 \item la scadenza di un timer o di un allarme.
  27 \item il tentativo di effettuare un'operazione di input/output che non può
  28   essere eseguita.
  29 \item una richiesta dell'utente di terminare o fermare il programma. In genere
  30   si realizza attraverso un segnale mandato dalla shell in corrispondenza
  31   della pressione di tasti come 'ctrl-c' o 'ctrl-z'.
  32 \item l'esecuzione di una \texttt{kill} o di una \texttt{raise} da parte del
  33   processo stesso o di un'altro (solo nel caso della \texttt{kill}).
  34 \end{itemize}
  35
  36 Ciascuno di questi eventi (tranne gli ultimi due che sono controllati
  37 dall'utente) comporta da parte del kernel la generazione un particolare tipo
  38 di segnale.
  39
  40
  41 \subsection{Le modalità di funzionamento}
  42 \label{sec:sig_semantics}
  43
  44 Quando un processo riceve un segnale il kernel esegue una apposita routine di
  45 gestione (il cosiddetto \textit{signal handler}) che può essere specificata
  46 dall'utente.  Negli anni il comportamento del sistema in risposta ai segnali è
  47 stato modificato in vari modi nelle differenti implementazioni di unix.
  48 Attualmente si possono individuare due tipologie fondamentali di comportamento
  49 dei segnali (dette semantiche) che vengono chiamate rispettivamente
  50 \textit{reliable} e \textit{unreliable}.
  51
  52 Nella semantica \textit{unreliable} la routine di gestione del segnale
  53 specificata dall'utente non resta installata una volta chiamata; è perciò a
  54 carico dell'utente stesso ripetere l'installazione all'interno della routine
  55 di gestione stessa in tutti i casi in cui si vuole che il signal handler
  56 esterno resti attivo.
  57
  58 Per questo motivo è possibile una race-condition in cui un secondo segnale
  59 arriva prima che il manipolatore abbia eseguito la re-installazione di se
  60 stesso, nel qual caso il segnale può essere perso o causare il comportamento
  61 originale assegnato al segnale (in genere la terminazione del processo).
  62 Questa è la ragione per cui detti segnali sono chiamati \textit{inaffidabili},
  63 in quanto la ricezione del segnale e la reinstallazione del suo manipolatore
  64 non sono operazioni atomiche.
  65
  66 Nel caso di implementazione inaffidabile le chiamate di sistema non
  67 sono fatte ripartire automaticamente quando sono interrotte da un segnale, per
  68 questo il programma deve controllare lo stato di uscita della chiamata al
  69 sistema e riperterla nel caso l'errore riportato da \texttt{errno} sia
  70 \texttt{EINTR}.
  71
  72 Inoltre in questo caso non esiste una modalità semplice per ottenere una
  73 operazione di pausa atomica (cioè mandare in sleep un processo fino all'arrivo
  74 di un segnale), dato che ci sono casi in cui un segnale può arrivare quando il
  75 programma non è in grado di accorgersene.
  76
  77 In caso di segnali \textit{reliable} invece il signal handler resta installato
  78 quando viene chiamato e i problemi precedenti sono evitati. Inoltre alcune
  79 chiamate di sistema possono essere fatte ripartire automaticamente e si può
  80 ottenere un'operazione di pausa atomica (usando la funzione POSIX
  81 \texttt{sigsuspend}).
  82
  83
  84 \subsubsection{Tipi di segnali}
  85 \label{sec:sig_types}
  86
  87 In generale gli eventi che generano i segnali si possono dividere in tre
  88 categorie principali: errori, eventi e richieste esplicite.
  89
  90 Un errore significa che un programma ha fatto qualcosa di sbagliato e non può
  91 continuare ad essere eseguito. Non tutti gli errori causano dei segnali, in
  92 genere la condizione di errore più comune comporta la restituzione di un
  93 codice di errore da parte di una funzione di libreria, sono gli errori che
  94 possono avvenire ovunque in un programma che causano l'emissione di un
  95 segnale, come le divisioni per zero o l'uso di indirizzi di memoria non validi.
  96
  97 Un evento esterno ha in genere a che fare con l'I/O o con altri processi;
  98 esempi di segnali di questo tipo sono quelli legati all'arrivo di dati di
  99 input, scadenze di un timer, terminazione di processi figli.
 100
 101 Una richiesta esplicita significa l'uso di una chiamata di sistema (come
 102 \texttt{kill} o \texttt{raise}) per la generazione di un segnale, cosa che
 103 viene fatta usualmente dalla shell quando l'utente invoca la sequenza di tasti
 104 di stop o di suspend, ma può essere pure inserita all'interno di un programma.
 105
 106 Si dice poi che i segnali possono essere \textit{asincroni} o
 107 \textit{sincroni}. Un segnale sincrono è legato ad una azione specifica di un
 108 programma ed è inviato (a meno che non sia bloccato) durante tale azione;
 109 molti errori generano segnali sincroni, così come la richiesta esplicita da
 110 parte del processo tramite le chiamate al sistema. Alcuni errori come la
 111 divisione per zero non sono completamente sincroni e possono arrivare dopo
 112 qualche istruzione.
 113
 114 I segnali asincroni sono generati da eventi fuori dal controllo del processo
 115 che li riceve e arrivano in tempi impredicibili nel corso dell'esecuzione del
 116 programma. Eventi esterni come la terminazione di un processo figlio generano
 117 segnali asincroni, così come le richieste di generazione di un segnale
 118 effettuate da altri processi.
 119
 120 In generale un tipo di segnale o è sincrono o è asincrono, salvo il caso in
 121 cui esso sia generato attraverso una richiesta esplicita tramite chiamata al
 122 sistema, nel qual caso qualunque tipo di segnale (quello scelto nella
 123 chiamata) può diventare sincrono o asincrono a seconda che sia generato
 124 internamente o esternamente al processo.
 125
 126 \section{La notifica dei segnali}
 127 \label{sec:sig_notification}
 128
 129 Quando un segnale viene generato il kernel prende nota del fatto; si dice così
 130 che diventa \textit{pending} (sospeso), e rimarrà tale fino al momento in cui
 131 verrà notificato al processo a cui deve essere inviato.
 132
 133 Normalmente l'invio al processo che deve ricevere il segnale è immediato, a
 134 meno che il segnale in questione non sia stato bloccato (\textit{blocked}) nel
 135 qual caso l'invio non avviene ed il segnale resta sospeso indefinitamente. Una
 136 volta però che esso venga sbloccato il segnale sarà subito notificato.
 137
 138 Una volta che il segnale viene notificato (che questo avvenga subito o dopo
 139 una attesa più o meno lunga) viene eseguita l'azione specificata per detto
 140 segnale. Per alcuni segnali (\texttt{SIGKILL} e \texttt{SIGSTOP}) questa azione
 141 è fissa e non può essere cambiata, ma per tutti gli altri il programma può
 142 specificare una scelta fra le tre seguenti:
 143
 144 \begin{itemize}
 145 \item ignorare il segnale
 146 \item utilizzare il manipolatore (\textit{signal handler}) specificato
 147 \item accettare l'azione di default per quel segnale.
 148 \end{itemize}
 149
 150 Il programma può specificare queste scelte usano le due routine
 151 \texttt{signal} e \texttt{sigaction}; se si è installato un manipolatore sarà
 152 quest'ultimo a intercettare il segnale ed ad essere eseguito, e mentre viene
 153 eseguito (onde evitare race conditions) il segnale viene bloccato.
 154
 155 Se l'azione specificata per un certo tipo di segnale è quella di ignorarlo
 156 questo sarà scartato immediatamente ogni volta che verrà generato, e questo
 157 avverrà anche se in quel momento il segnale è bloccato. Per questo un segnale
 158 ignorato non sarà mai notificato, anche se in seguito si sarà specificata una
 159 diversa azione per lo stesso segnale.
 160
 161 Se arriva un segnale per il quale non è stato specificata un'azione viene
 162 utilizzata l'azione standard. Questa è diversa da segnale a segnale (come
 163 vedremo in \secref{sec:sig_standard}) ma per la maggior parte essa comporta la
 164 terminazione del processo, per alcuni che invece rappresentano eventi innocui
 165 l'azione standard è di non fare nulla.
 166
 167 Quando un segnale termina un processo, il padre può determinare la causa della
 168 terminazione esaminando il codice di stato riportato delle funzioni
 169 \texttt{wait} e \texttt{waitpid} in cui è riportato anche se la causa è un
 170 segnale e nel caso quale; questo è il modo in cui la shell determina i motivi
 171 della terminazione di un programma e scrive un eventuale messaggio di errore.
 172
 173 I segnali che rappresentano errori del programma (divisione per zero o
 174 violazioni di accesso) hanno anche la caratteristica di scrivere un file
 175 \textit{core dump} che registra lo stato del processo prima della terminazione
 176 e può essere esaminato da un debugger per investigare sulla causa dell'errore.
 177 Lo stesso avviene se i suddetti segnale vengono generati artificialmente con
 178 una \texttt{kill}.
 179
 180
 181
 182 \subsection{I segnali standard}
 183 \label{sec:sig_standard}
 184
 185 Esaminiamo ora i vari segnali disponibili e le loro caratteristiche.
 186 Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
 187 diretto di questo numero da parte dei programmi è da evitare, in quanto esso
 188 può variare a seconda dell'implementazione del sistema.
 189
 190 Per questo ad ogni tipo di segnale viene associato un nome, che corrisponde
 191 tramite una macro di preprocessore, al suddetto numero, e sono questi nomi,
 192 che sono standardizzati e uniformi rispetto alle varie implementazioni, che si
 193 devono usare nei programmi. Tutti i nomi e le funzioni che concernono i
 194 segnali sono definiti nell'header di sistema \texttt{signal.h}.
 195
 196 Il numero totale di segnali presenti è dato dalla macro \texttt{NSIG}, e dato
 197 che i numeri dei segnali sono allocati progressivamente, essa corrisponde
 198 anche al successivo del valore numerico assegnato all'ultimo segnale definito,
 199 in \ntab\ si è riportato l'elenco completo dei segnali definiti in Linux,
 200 comparati con quelli definiti in vari standard.
 201
 202 \begin{table}[htb]
 203   \centering
 204   \begin{tabular}[c]{|l|c|c|c||c|l|}
 205     \hline
 206     Segnale  & POSIX.1 & SUSv2 & Linux  &Azione &  Descrizione                \\
 207     \hline
 208     \hline
 209     SIGHUP   &$\bullet$&&$\bullet$&  A  & Hangup                                \\
 210     SIGINT   &$\bullet$&&$\bullet$&  A  & Interrupt from keyboard               \\
 211     SIGQUIT  &$\bullet$&&$\bullet$&  C  & Quit from keyboard                    \\
 212     SIGILL   &$\bullet$&&$\bullet$&  C  & Illegal Instruction                   \\
 213     SIGABRT  &$\bullet$&&$\bullet$&  C  & Abort signal from abort(3)            \\
 214     SIGFPE   &$\bullet$&&$\bullet$&  C  & Floating point exception              \\
 215     SIGKILL  &$\bullet$&&$\bullet$& AEF & Kill signal                           \\
 216     SIGSEGV  &$\bullet$&&$\bullet$&  C  & Invalid memory reference              \\
 217     SIGPIPE  &$\bullet$&&$\bullet$&  A  & Broken pipe                           \\
 218     SIGALRM  &$\bullet$&&$\bullet$&  A  & Timer signal from alarm(2)            \\
 219     SIGTERM  &$\bullet$&&$\bullet$&  A  & Termination signal                    \\
 220     SIGUSR1  &$\bullet$&&$\bullet$&  A  & User-defined signal 1                 \\
 221     SIGUSR2  &$\bullet$&&$\bullet$&  A  & User-defined signal 2                 \\
 222     SIGCHLD  &$\bullet$&&$\bullet$&  B  & Child stopped or terminated           \\
 223     SIGCONT  &$\bullet$&&$\bullet$&     & Continue if stopped                   \\
 224     SIGSTOP  &$\bullet$&&$\bullet$& DEF & Stop process                          \\
 225     SIGTSTP  &$\bullet$&&$\bullet$&  D  & Stop typed at tty                     \\
 226     SIGTTIN  &$\bullet$&&$\bullet$&  D  & tty input for background process      \\
 227     SIGTTOU  &$\bullet$&&$\bullet$&  D  & tty output for background process     \\
 228     SIGBUS    &&$\bullet$&$\bullet$& C & Bus error (bad memory access)         \\
 229     SIGPOLL   &&$\bullet$&$\bullet$& A & Pollable event (Sys V). Synonym of SIGIO\\
 230     SIGPROF   &&$\bullet$&$\bullet$& A & Profiling timer expired               \\
 231     SIGSYS    &&$\bullet$&$\bullet$& C & Bad argument to routine (SVID)        \\
 232     SIGTRAP   &&$\bullet$&$\bullet$& C & Trace/breakpoint trap                 \\
 233     SIGURG    &&$\bullet$&$\bullet$& B & Urgent condition on socket (4.2 BSD)  \\
 234     SIGVTALRM &&$\bullet$&$\bullet$& A & Virtual alarm clock (4.2 BSD)         \\
 235     SIGXCPU   &&$\bullet$&$\bullet$& C & CPU time limit exceeded (4.2 BSD)     \\
 236     SIGXFSZ   &&$\bullet$&$\bullet$& C & File size limit exceeded (4.2 BSD)    \\
 237     SIGIOT    &&&$\bullet$& C &     IOT trap. A synonym for SIGABRT        \\
 238     SIGEMT    &&&$\bullet$&   &                                            \\
 239     SIGSTKFLT &&&$\bullet$& A &     Stack fault on coprocessor             \\
 240     SIGIO     &&&$\bullet$& A &     I/O now possible (4.2 BSD)             \\
 241     SIGCLD    &&&$\bullet$&   &     A synonym for SIGCHLD                  \\
 242     SIGPWR    &&&$\bullet$& A &     Power failure (System V)               \\
 243     SIGINFO   &&&$\bullet$&   &     A synonym for SIGPWR                   \\
 244     SIGLOST   &&&$\bullet$& A &     File lock lost                         \\
 245     SIGWINCH  &&&$\bullet$& B &     Window resize signal (4.3 BSD, Sun)    \\
 246     SIGUNUSED &&&$\bullet$& A &     Unused signal (will be SIGSYS)         \\
 247     \hline
 248   \end{tabular}
 249   \caption{Lista dei segnali in Linux}
 250   \label{tab:sign_signal_list}
 251 \end{table}
 252
 253
 254 \subsubsection{Segnali di errore di programma}
 255
 256 Questi segnali sono generati quando il sistema, o in certi casi direttamente
 257 l'hardware (come per i page fault non validi) rileva un qualche errore
 258 insanabile nel programma in esecuzione. In generale la generazione di questi
 259 segnali significa che il programma ha dei gravi problemi (ad esempio ha
 260 dereferenziato un puntatore non valido o ha eseguito una operazione aritmetica
 261 proibita) e l'esecuzione non può essere proseguita.
 262
 263 In genere si intercettano questi segnali per permettere al programma di
 264 terminare in maniera pulita, ad esempio per ripristinare i settaggi della
 265 console o eliminare i file di lock prima dell'uscita.  In questo caso il
 266 manipolatore deve concludersi ripristinando l'azione di default e rialzando il
 267 segnale, in questo modo il programma si concluderà senza effetti spiacevoli,
 268 ma riportando lo stesso stato di uscita che avrebbe avuto se il manipolatore
 269 non ci fosse stato.
 270
 271 L'azione di default per tutti questi segnali è causare la terminazione del
 272 processo che li ha causati. In genere oltre a questo il segnale provoca pure
 273 la registrazione su disco di un \textit{core dump file} che viene scritto in
 274 un file \texttt{core} nella directory corrente del processo al momento
 275 dell'errore.
 276
 277 Questi segnali sono:
 278
 279 \begin{itemize}
 280 \item \texttt{SIGFPE} Riporta un errore aritmetico fatale. Benché il nome
 281   derivi da \textit{floating point exception} si applica a tutti gli errori
 282   aritmetici compresa la divisione per zero e l'overflow.
 283
 284 %   Per questo segnale le cose sono complicate dal fatto che possono esserci
 285 %   molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
 286 %   standard IEEE per le operazioni in virgola mobile definisce vaire eccezioni
 287 %   aritmetiche e richiede che esse siano notificate.
 288 \item \texttt{SIGILL} Il nome deriva da \textit{illegal instruction},
 289   significa che il programma sta cercando di eseguire una istruzione
 290   privilegiata o inesistente, in generale del codice illegale. Poiché il
 291   compilatore del C genera del codice valido si ottiene questo segnale se il
 292   file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
 293   Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
 294   posto di un puntatore a funzione, o si eccede la scrittura di un vettore di
 295   una variabile locale, andando a corrompere lo stack. Lo stesso segnale viene
 296   generato in caso di overflow dello stack o di problemi nell'esecuzione di di
 297   un signal handler.
 298
 299 \item \texttt{SIGSEGV} Il nome deriva da \textit{segment violation}, e
 300   significa che il programma sta cercando di leggere o scrivere in una zona di
 301   memoria protetta al di fuori di quella che gli è stata riservata dal
 302   sistema. In genere è il meccanismo della protezione della memoria che si
 303   accorge dell'errore ed il kernel genera il segnale.
 304
 305   È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
 306   inizializzato leggendo al di la della fine di un vettore.
 307
 308 \item \texttt{SIGBUS}
 309 \item \texttt{SIGABRT}
 310 \item \texttt{SIGTRAP}
 311 \item \texttt{SIGSYS}
 312
 313 \end{itemize}
 314