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 relativi al controllo di sessione.
 166
 167
 168 \subsection{La funzione \func{fork}}
 169 \label{sec:proc_fork}
 170
 171 La funzione \func{fork} è la funzione fondamentale della gestione dei processi
 172 in unix; come si è detto l'unico modo di creare un nuovo processo è attraverso
 173 l'uso di questa funzione, che è quindi la base per il multitasking; il protipo
 174 della funzione è:
 175
 176 \begin{functions}
 177   \headdecl{sys/types.h}
 178   \headdecl{unistd.h}
 179
 180   \funcdecl{pid\_t fork(void)}
 181
 182   Restituisce zero al padre e il \acr{pid} al figlio in caso di successo,
 183   ritorna -1 al padre (senza creare il figlio) in caso di errore;
 184   \texttt{errno} può assumere i valori:
 185   \begin{errlist}
 186   \item \macro{EAGAIN} non ci sono risorse sufficienti per creare un'altro
 187     processo (per allocare la tabella delle pagine e le strutture del task) o
 188     si è esaurito il numero di processi disponibili.
 189   \item \macro{ENOMEM} non è stato possibile allocare la memoria per le
 190     strutture necessarie al kernel per creare il nuovo processo.
 191   \end{errlist}
 192 \end{functions}
 193
 194 Dopo l'esecuzione di una \func{fork} sia il processo padre che il processo
 195 figlio continuano ad essere eseguiti normalmente alla istruzione seguente la
 196 \func{fork}; il processo figlio è però una copia del padre, e riceve una copia
 197 dei segmenti di testo, stack e dati (vedi \secref{sec:proc_mem_layout}), ed
 198 esegue esattamente lo stesso codice del padre, ma la memoria è copiata, non
 199 condivisa\footnote{In generale il segmento di testo, che è identico, è
 200   condiviso e tenuto in read-only, linux poi utilizza la tecnica del
 201   \textit{copy-on-write}, per cui la memoria degli altri segmenti viene
 202   copiata dal kernel per il nuovo processo solo in caso di scrittura, rendendo
 203   molto più efficiente il meccanismo} pertanto padre e figlio vedono variabili
 204 diverse.
 205
 206 La differenza che si ha nei due processi è che nel processo padre il valore di
 207 ritorno della funzione fork è il \acr{pid} del processo figlio, mentre nel
 208 figlio è zero; in questo modo il programma può identificare se viene eseguito
 209 dal padre o dal figlio.
 210
 211 \begin{figure}[!htb]
 212   \footnotesize
 213   \begin{lstlisting}{}
 214 #include <errno.h>       /* error definitions and routines */
 215 #include <stdlib.h>      /* C standard library */
 216 #include <unistd.h>      /* unix standard library */
 217 #include <stdio.h>       /* standard I/O library */
 218 #include <string.h>      /* string functions */
 219
 220 /* Help printing routine */
 221 void usage(void);
 222
 223 int main(int argc, char *argv[])
 224 {
 225 /*
 226  * Variables definition
 227  */
 228     int i;
 229     int nchild;
 230     pid_t pid;
 231
 232     ...        /* handling options */
 233
 234     /* There must be remaing parameters */
 235     if (optind == argc) {
 236         usage();
 237     }
 238     nchild = atoi(argv[optind]);
 239     printf("Test for forking %d child\n", nchild);
 240     /* loop to fork children */
 241     for (i=0; i<nchild; i++) {
 242         if ( (pid = fork()) < 0) {
 243             printf("Error on %d child creation, %s\n", i, strerror(errno));
 244         }
 245         if (pid == 0) {   /* child */
 246             printf("Child %d successfully executing\n", i++);
 247             sleep(2);
 248             printf("Child %d exiting\n", i);
 249             exit(0);
 250         } else {          /* parent */
 251             printf("Spawned %d child, pid %d \n", i, pid);
 252         }
 253     }
 254     /* normal exit */
 255     return 0;
 256 }
 257   \end{lstlisting}
 258   \caption{Esempio di codice per la creazione di nuovi processi.}
 259   \label{fig:proc_fork_code}
 260 \end{figure}
 261
 262 Si noti come la funzione \func{fork} ritorni \textbf{due} volte: una nel padre
 263 e una nel figlio. La sola differenza che si ha nei due processi è il valore di
 264 ritorno restituito dalla funzione, che nel padre è il \acr{pid} del figlio
 265 mentre nel figlio è zero; in questo modo il programma può identificare se
 266 viene eseguito dal padre o dal figlio.
 267
 268 La scelta di questi valori comunque non è casuale, un processo infatti può
 269 avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che
 270 permette di identificare quello appena creato; al contrario un figlio ha
 271 sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
 272 \func{getppid}, vista in \secref{sec:proc_pid}) e si usa il valore nullo, che
 273 non può essere il \acr{pid} di nessun processo.
 274
 275 In \curfig\ si è riportato il corpo del codice dell'esempio \cmd{forktest},
 276 che ci permette di illustrare l'uso della funzione \func{fork}, creando un
 277 numero di figli specificato a linea di comando; il codice completo, compresa
 278 la parte che gestisce le opzioni a riga di comando, è disponibile nel file
 279 \file{ForkTest.c}.
 280
 281 Decifrato il numero di figli da creare, il ciclo principale del programma
 282 (\texttt{\small 28--40}) esegue in successione la creazione dei processi figli
 283 controllando il successo della chiamata a \func{fork} (\texttt{\small
 284   29--31}); ciascun figlio (\texttt{\small 29--31}) si limita a stampare il
 285 suo numero di successione, attendere 3 secondi e scrivere un messaggio prima
 286 di uscire. Il processo padre invece (\texttt{\small 29--31}) stampa un
 287 messaggio di creazione e procede nell'esecuzione del ciclo. Se eseguiamo il
 288 comando otterremo come output sul terminale:
 289 \begin{verbatim}
 290 [piccardi@selidor sources]$ ./forktest 5
 291 Test for forking 5 child
 292 Spawned 1 child, pid 840
 293 Child 1 successfully executing
 294 Child 2 successfully executing
 295 Spawned 2 child, pid 841
 296 Spawned 3 child, pid 842
 297 Child 3 successfully executing
 298 Spawned 4 child, pid 843
 299 Child 4 successfully executing
 300 Child 5 successfully executing
 301 Spawned 5 child, pid 844
 302 [piccardi@selidor sources]$ Child 2 exiting
 303 Child 1 exiting
 304 Child 4 exiting
 305 Child 3 exiting
 306 Child 5 exiting
 307 \end{verbatim}
 308
 309 Come si vede non si può dire quale processo fra il padre ed il figlio venga
 310 eseguito per primo\footnote{anche se nel kernel 2.4.x era stato introdotto un
 311   meccanismo che metteva in esecuzione sempre il xxx per primo (TODO
 312   recuperare le informazioni esatte)} dopo la chiamata a \func{fork}, nel caso
 313 mostrato sopra ad esempio si può notare come dopo la creazione il secondo ed
 314 il quinto figlio sia stato stati eseguiti per primi, mantre per gli altri
 315 figli è stato eseguito per primo il padre.
 316
 317 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
 318 scheduling usato dal kernel, dalla particolare situazione in si trova la
 319 macchina al momento della chiamata, risultando del tutto impredicibile.
 320 Eseguendo più volte il programma di prova, si sono ottenute situazioni
 321 completamente diverse, compreso caso in cui il processo padre ha eseguito più
 322 di una \func{fork} prima che uno dei figli venisse messo in
 323 esecuzione.
 324
 325 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
 326 istruzioni del codice fra padre e figli, e se è necessaria una qualche forma
 327 di precedenza occorrerà provvedere ad espliciti meccanismi di
 328 sincronizzazione, pena il rischio di incorrere nelle cosiddette \textit{race
 329   conditions}.
 330
 331 Si ricordi inoltre che come accennato, essendo i segmenti di memoria
 332 utilizzati dai singoli processi completamente separati, le modifiche delle
 333 variabili nei processi figli (come l'incremento di \var{i} in \texttt{\small
 334   33}) saranno effettive solo per essi, e non hanno alcun effetto sul valore
 335 che le stesse variabili hanno nel processo padre.
 336
 337
 338 \subsection{Le funzioni \texttt{wait} e  \texttt{waitpid}}
 339 \label{sec:proc_wait}
 340
 341
 342 \subsection{Le funzioni \texttt{exec}}
 343 \label{sec:proc_exec}
 344
 345
 346
 347
 348 \section{Il controllo di accesso}
 349 \label{sec:proc_perms}
 350
 351 In questa sezione esamineremo le problematiche relative al controllo di
 352 accesso dal punto di vista del processi; gli identificativi usati, come questi
 353 vengono modificati nella creazione e nel lancio di nuovi processi, e le varie
 354 funzioni per la loro manipolazione diretta.
 355
 356
 357 \subsection{Utente e gruppo di un processo}
 358 \label{sec:proc_user_group}
 359
 360 Abbiamo già accennato in \secref{sec:intro_multiuser} ad ogni utente ed gruppo
 361 sono associati due identificatori univoci, lo \acr{uid} e il \acr{gid} che li
 362 contraddistinguono nei confonti del kernel. Questi identificatori stanno alla
 363 base del sistema di permessi e protezioni di un sistema unix, e vengono usati
 364 anche nella gestione dei privilegi di accesso dei processi.
 365
 366 In realtà ad ogni processo è associato un certo numero di identificatori, il
 367 cui elenco è riportato \ntab, in genere questi derivano direttamente
 368 dall'utente che ha lanciato il processo (attraverso i valori di \acr{uid} e
 369 \acr{gid}), e vengono usati sia per il controllo di accesso ai file che per la
 370 gestione dei privilegi associati ai processi stessi.
 371 \begin{table}[htb]
 372   \centering
 373   \begin{tabular}[c]{|c|l|l|}
 374     \hline
 375     Sigla & Significato & Utilizzo \\
 376     \hline
 377     \hline
 378     \acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato
 379     il programma\\
 380     \acr{rgid} & \textit{real group id} & indica il gruppo reale dell'utente
 381     che ha lanciato il programma \\
 382     \acr{euid} & \textit{effective user id} & indica l'utente effettivo usato
 383     dal programma \\
 384     \acr{egid} & \textit{effective group id} & indica il gruppo effettivo usato
 385     dal programma \\
 386                & \textit{supplementary group id} & indica i gruppi cui
 387     l'utente appartiene  \\
 388     \acr{suid} & \textit{saved user id} & indica l'utente  \\
 389     \acr{sgid} & \textit{daved group id} & indica il gruppo  \\
 390     \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per
 391     il filesystem \\
 392     \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo
 393     per il filesystem  \\
 394     \hline
 395   \end{tabular}
 396   \caption{Identificatori di utente e gruppo associati a ciascun processo.}
 397   \label{tab:proc_uid_gid}
 398 \end{table}
 399
 400 Il \textit{real user id} e il \textit{real group id} indicano l'utente che ha
 401 lanciato il processo, e vengono settati al login al valore standard di
 402 \acr{uid} e \acr{gid} dell'utente letti direttamente da \file{/etc/passwd}.
 403 Questi non vengono mai cambiati nella creazione di nuovi processi e restano
 404 sempre gli stessi per tutti i processi avviati in una sessione. In realtà è
 405 possibile modificarli (vedi \secref{sec:proc_setuid}), ma solo per un processo
 406 che abbia i privilegi di amministratore (ed è così infatti che \cmd{login},
 407 che gira con i privilegi di amministratore, li setta ai valori corrispondenti
 408 all'utente che entra nel sistema).
 409
 410 L'\textit{effective user id}, l'\textit{effective group id} e gli eventuali
 411 \textit{supplementary group id} sono gli identificativi usati per il controllo
 412 di accesso ai file secondo quanto descritto in dettaglio in
 413 \secref{sec:file_perm_overview}. Normalmente sono uguali al \textit{real user
 414   id} e al \textit{real group id}, a meno che il file posto in esecuzione non
 415 abbia i bit \acr{suid} o \acr{sgid} settati, nel qual caso vengono settati
 416 rispettivamente all'\acr{uid} e \acr{gid} del file.
 417
 418 Il \textit{saved user id} e il \textit{saved group id} sono copie
 419 dell'\textit{effective user id} e dell'\textit{effective group id} del
 420 processo padre, e vengono settati all'avvio del processo, prima che
 421 \textit{effective user id} e \textit{effective group id} vengano modificati
 422 per tener conto di eventuali \acr{suid} o \acr{sgid}.
 423
 424
 425 \subsection{Le funzioni \texttt{setuid} e \texttt{setgid}}
 426 \label{sec:proc_setuid}
 427
 428
 429 \subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}}
 430 \label{sec:proc_seteuid}
 431