prochand.tex

   1 \chapter{La gestione dei processi}
   2 \label{cha:process_handling}
   3
   4 Come accennato nell'introduzione in un sistema unix ogni attività del sistema
   5 viene svolta tramite i processi.  In sostanza i processi costituiscono l'unità
   6 base per l'allocazione e l'uso delle risorse del sistema.
   7
   8 Nel precedente capitolo abbiamo visto come funziona un singolo processo, in
   9 questo capitolo affronteremo i dettagli della creazione e della distruzione
  10 dei processi, della gestione dei loro attributi e privilegi, e di tutte le
  11 funzioni a questo connesse.
  12
  13
  14 \section{Introduzione}
  15 \label{sec:proc_gen}
  16
  17 Partiremo con una introduzione generale ai concetti che stanno alla base della
  18 gestione dei processi in unix. Introdurremo in questa sezione l'architettura
  19 della gestione dei processi e le sue principali caratteristiche, e daremo una
  20 panoramica sull'uso delle principali funzioni per la gestione dei processi.
  21
  22 \subsection{La gerarchia dei processi}
  23 \label{sec:proc_hierarchy}
  24
  25 A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
  26 generazione di nuovi processi è un'operazione privilegiata) una delle
  27 caratteristiche di unix (che esamineremo in dettaglio più avanti) è che
  28 qualunque processo può a sua volta generarne altri, detti processi figli
  29 (\textit{child process}). Ogni processo è identificato presso il sistema da un
  30 numero unico, il \acr{pid} (da \textit{process identifier}).
  31
  32 Una seconda caratteristica è che la generazione di un processo è una
  33 operazione separata rispetto al lancio di un programma. In genere la sequenza
  34 è sempre quella di creare un nuovo processo, il quale si eseguirà, in un passo
  35 successivo, il programma voluto: questo è ad esempio quello che fa la shell
  36 quando mette in esecuzione il programma che gli indichiamo nella linea di
  37 comando.
  38
  39 Una terza caratteristica è che ogni processo viene sempre generato da un altro
  40 che viene chiamato processo genitore (\textit{parent process}). Questo vale
  41 per tutti i processi, con una eccezione (dato che ci deve essere un punto di
  42 partenza), esiste sempre infatti un processo speciale, che normalmente è
  43 \cmd{/sbin/init}, che viene lanciato dal kernel quando questo ha finito la
  44 fase di avvio, esso essendo il primo processo lanciato ha sempre il \acr{pid}
  45 uguale a 1 e non è figlio di nessuno.
  46
  47 Questo è ovviamente un processo speciale, che in genere si occupa di far
  48 partire tutti gli processi altri necessari al funzionamento del sistema,
  49 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
  50 amministrativi nelle operazioni ordinarie del sistema (torneremo si alcuni di
  51 essi in \secref{}) e non può mai essere terminato. La struttura del sistema
  52 comunque consente di lanciare al posto di \cmd{init} qualunque altro programma
  53 (e in casi di emergenza, ad esempio se il file di \cmd{init} si fosse
  54 corrotto, è possibile farlo ad esempio passando la riga \cmd{init=/bin/sh}
  55 all'avvio).
  56
  57 Dato che tutti i processi successivi sono comunque generati da \cmd{init} o da
  58 suoi figli tutto ciò comporta che, i processi sono organizzati gerarchicamente
  59 dalla relazione fra genitori e figli, in maniera analoga a come i file sono
  60 organizzati in un albero di directory con alla base \file{/} (si veda
  61 \secref{sec:file_file_struct}); in questo caso alla base dell'albero c'è il
  62 processo \cmd{init} che è progenitore di ogni altro processo\footnote{in
  63   realtà questo non è del tutto vero, in Linux ci sono alcuni processi che pur
  64   comparendo come figli di init (ad esempio in \cmd{pstree}) sono generati
  65   direttamente dal kernel, come \cmd{keventd}, \cmd{kswapd}, etc.}.
  66
  67
  68 \subsection{Una panoramica sulle funzioni di gestione}
  69 \label{sec:proc_handling_intro}
  70
  71 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
  72 una system call, Linux però usa un'altra nomenclatura, e la funzione fork è
  73 basata a sua volta sulla system call \func{\_\_clone}, che viene usata anche
  74 per generare i \textit{thread}.  Il processo figlio creato dalla \func{fork} è
  75 una copia identica del processo processo padre, ma ha nuovo \acr{pid} e viene
  76 eseguito in maniera indipendente (le differenze fra padre e figlio sono
  77 affrontate in dettaglio in \secref{sec:proc_fork}).
  78
  79 Se si vuole che il processo padre si fermi fino alla conclusione del processo
  80 figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
  81 funzione \func{wait} o la funzione \func{waitpid}; queste funzioni
  82 restituiscono anche una informazione abbastanza limitata (il codice di uscita)
  83 sulle cause della terminazione del processo.
  84
  85 Quando un processo ha concluso il suo compito o ha incontrato un errore non
  86 risolvibile esso può essere terminato con la funzione \func{exit} (si veda
  87 quanto discusso in \secref{sec:proc_termination}). La vita del processo però
  88 termina solo quando la notifica della sua conclusione viene ricevuta dal
  89 processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
  90 associate vengono rilasciate.
  91
  92 Avere due processi che eseguono esattamente lo stesso codice non è molto
  93 utile, normalmente si genera un secondo processo per affidargli l'esecuzione
  94 di un compito specifico (ad esempio gestire una connessione dopo che questa è
  95 stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
  96 quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
  97 coi processi che è la \func{exec}.
  98
  99 Il programma che un processo sta eseguendo si chiama immagine del processo (o
 100 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
 101 caricare un'altro programma da disco sostituendo quest'ultimo all'immagine
 102 corrente; questo fa si che l'immagine precedente venga completamente
 103 cancellata. Questo significa che quando il nuovo programma esce anche il
 104 processo termina, e non si può tornare alla precedente immagine.
 105
 106 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
 107 particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
 108 prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
 109 non ritorna mai (in quanto con essa viene eseguito un altro programma).
 110
 111
 112
 113 \section{La gestione dei processi}
 114 \label{sec:proc_handling}
 115
 116 In questa sezione tratteremo le funzioni per la gestione dei processi, a
 117 partire dalle funzioni elementari che permettono di leggerne gli
 118 identificatori, alle varie funzioni di manipolazione dei processi, che
 119 riguardano la lore creazione, terminazione, e la messa in esecuzione di altri
 120 programmi.
 121
 122
 123 \subsection{Gli identificatori dei processi}
 124 \label{sec:proc_pid}
 125
 126 Come accennato nell'introduzione ogni processo viene identificato dal sistema
 127 da un numero identificativo unico, il \textit{process id} o \acr{pid};
 128 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
 129 intero con segno (nel caso di Linux e delle glibc il tipo usato è \type{int}).
 130
 131 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
 132 processo viene creato, fino ad un limite massimo (in genere essendo detto
 133 numero memorizzato in un intero a 16 bit si arriva a 32767) oltre il quale si
 134 riparte dal numero più basso disponibile (FIXME: verificare, non sono sicuro).
 135 Per questo motivo processo il processo di avvio (\cmd{init}) ha sempre il
 136 \acr{pid} uguale a uno.
 137
 138 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
 139 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
 140 \textit{parent process id}) ed è normalmente utilizzato per il controllo di
 141 sessione.  Questi due identificativi possono essere ottenuti da programma
 142 usando le funzioni:
 143 \begin{functions}
 144 \headdecl{sys/types.h}
 145 \headdecl{unistd.h}
 146 \funcdecl{pid\_t getpid(void)} restituisce il pid del processo corrente.
 147 \funcdecl{pid\_t getppid(void)} restituisce il pid del padre del processo
 148     corrente.
 149
 150 Entrambe le funzioni non riportano condizioni di errore.
 151 \end{functions}
 152
 153 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende il
 154 candidato ideale per generare ultieriori indicatori associati al processo di
 155 cui diventa possibile garantire l'unicità: ad esempio la funzione
 156 \func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid} per
 157 generare un pathname univoco, che non potrà essere replicato da un'altro
 158 processo che usi la stessa funzione.
 159
 160 Tutti i processi figli dello stesso processo padre sono detti
 161 \textit{sibling}, questa è un'altra delle relazioni usate nel controllo di
 162 sessione, in cui si raggruppano tutti i processi creati su uno stesso
 163 terminale una volta che si è effettuato il login. Torneremo su questo
 164 argomento in \secref{cap:terminal}, dove esamineremo tutti gli altri
 165 identificativi associati ad un processo.
 166
 167 \subsection{Utente e gruppo di un processo}
 168 \label{sec:proc_user_group}
 169
 170 Come accennato in \secref{sec:intro_multiuser} ad ogni utente ed gruppo sono
 171 associati due identificatori univoci, lo \acr{uid} e il \acr{gid} che li
 172 contraddistinguono nei confonti del kernel. Questi identificatori stanno alla
 173 base del sistema di permessi e protezioni di un sistema unix, e vengono usati
 174 anche nella gestione dei privilegi di accesso dei processi.
 175
 176 Abbiamo già accennato in \secref{sec:file_perm_overview} che ad ogni processo
 177 associato un certo numero di identificatori (riportati \ntab) che fanno
 178 riferimento all'utente che ha lanciato il processo (attraverso i valori di
 179 \acr{uid} e \acr{gid}), e vengono usati sia per il controllo di accesso ai
 180 file che per la gestione dei privilegi associati ai processi stessi.
 181 \begin{table}[htb]
 182   \centering
 183   \begin{tabular}[c]{|c|l|l|}
 184     \hline
 185     Sigla & Significato & Utilizzo \\
 186     \hline
 187     \hline
 188     \acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato
 189     il programma\\
 190     \acr{rgid} & \textit{real group id} & indica il gruppo reale dell'utente
 191     che ha lanciato il programma \\
 192     \acr{euid} & \textit{effective user id} & indica l'utente effettivo usato
 193     dal programma \\
 194     \acr{egid} & \textit{effective group id} & indica il gruppo effettivo usato
 195     dal programma \\
 196                & \textit{supplementary group id} & indica i gruppi cui
 197     l'utente appartiene  \\
 198     \acr{suid} & \textit{saved user id} & indica l'utente  \\
 199     \acr{sgid} & \textit{daved group id} & indica il gruppo  \\
 200     \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per
 201     il filesystem \\
 202     \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo
 203     per il filesystem  \\
 204     \hline
 205   \end{tabular}
 206   \caption{Identificatori di utente e gruppo associati a ciascun processo.}
 207   \label{tab:proc_uid_gid}
 208 \end{table}
 209
 210
 211
 212
 213
 214 \subsection{La funzione \func{fork}}
 215 \label{sec:proc_fork}
 216
 217 La funzione \func{fork} è la funzione fondamentale della gestione dei processi
 218 in unix; come si è detto l'unico modo di creare un nuovo processo è attraverso
 219 l'uso di questa funzione, che è quindi la base per il multitasking; il protipo
 220 della funzione è:
 221
 222 \begin{functions}
 223   \headdecl{sys/types.h}
 224   \headdecl{unistd.h}
 225
 226   \funcdecl{pid\_t fork(void)}
 227
 228   Restituisce zero al padre e il \acr{pid} al figlio in caso di successo,
 229   ritorna -1 al padre (senza creare il figlio) in caso di errore;
 230   \texttt{errno} può assumere i valori:
 231   \begin{errlist}
 232   \item \macro{EAGAIN} non ci sono risorse sufficienti per creare un'altro
 233     processo (per allocare la tabella delle pagine e le strutture del task) o
 234     si è esaurito il numero di processi disponibili.
 235   \item \macro{ENOMEM} non è stato possibile allocare la memoria per le
 236     strutture necessarie al kernel per creare il nuovo processo.
 237   \end{errlist}
 238 \end{functions}
 239
 240 Dopo l'esecuzione di una \func{fork} sia il processo padre che il processo
 241 figlio continuano ad essere eseguiti normalmente, ed il processo figlio esegue
 242 esattamente lo stesso codice del padre. La sola differenza è che nel processo
 243 padre il valore di ritorno della funzione fork è il \acr{pid} del processo
 244 figlio, mentre nel figlio è zero; in questo modo il programma può identificare
 245 se viene eseguito dal padre o dal figlio.
 246
 247
 248
 249 \subsection{Le funzioni \texttt{wait} e  \texttt{waitpid}}
 250 \label{sec:proc_wait}
 251
 252 \subsection{Le funzioni \texttt{exec}}
 253 \label{sec:proc_exec}
 254
 255
 256
 257
 258 \section{Il controllo di accesso}
 259 \label{sec:proc_perms}
 260
 261
 262 \subsection{Le funzioni \texttt{setuid} e \texttt{setgid}}
 263 \label{sec:proc_setuid}
 264
 265
 266 \subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}}
 267 \label{sec:proc_seteuid}
 268