3 %% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Prefazione",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
11 \chapter{La gestione dei processi}
12 \label{cha:process_handling}
14 Come accennato nell'introduzione in un sistema Unix tutte le operazioni
15 vengono svolte tramite opportuni processi. In sostanza questi ultimi vengono
16 a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
18 Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come
19 unità a se stante, in questo esamineremo il funzionamento dei processi
20 all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
21 della terminazione dei processi, della gestione dei loro attributi e
22 privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione
23 finale introdurremo alcune problematiche generiche della programmazione in
24 ambiente multitasking.
27 \section{Introduzione}
30 Inizieremo con un'introduzione generale ai concetti che stanno alla base della
31 gestione dei processi in un sistema unix-like. Introdurremo in questa sezione
32 l'architettura della gestione dei processi e le sue principali
33 caratteristiche, dando una panoramica sull'uso delle principali funzioni di
37 \subsection{L'architettura della gestione dei processi}
38 \label{sec:proc_hierarchy}
40 A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
41 generazione di nuovi processi è un'operazione privilegiata) una delle
42 caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
43 qualunque processo può a sua volta generarne altri, detti processi figli
44 (\textit{child process}). Ogni processo è identificato presso il sistema da un
45 numero univoco, il cosiddetto \textit{process identifier} o, più brevemente,
46 \acr{pid}, assegnato in forma progressiva (vedi \secref{sec:proc_pid}) quando
47 il processo viene creato.
49 Una seconda caratteristica di un sistema Unix è che la generazione di un
50 processo è un'operazione separata rispetto al lancio di un programma. In
51 genere la sequenza è sempre quella di creare un nuovo processo, il quale
52 eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
53 quello che fa la shell quando mette in esecuzione il programma che gli
54 indichiamo nella linea di comando.
56 Una terza caratteristica è che ogni processo è sempre stato generato da un
57 altro, che viene chiamato processo padre (\textit{parent process}). Questo
58 vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
59 punto di partenza esiste un processo speciale (che normalmente è
60 \cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
61 di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
62 \acr{pid} uguale a 1 e non è figlio di nessun altro processo.
64 Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
65 partire tutti gli altri processi necessari al funzionamento del sistema,
66 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
67 amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
68 essi in \secref{sec:proc_termination}) e non può mai essere terminato. La
69 struttura del sistema comunque consente di lanciare al posto di \cmd{init}
70 qualunque altro programma, e in casi di emergenza (ad esempio se il file di
71 \cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
72 posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
77 [piccardi@gont piccardi]$ pstree -n
94 |-bash---startx---xinit-+-XFree86
95 | `-WindowMaker-+-ssh-agent
103 | |-wterm---bash---pstree
104 | `-wterm---bash-+-emacs
110 \caption{L'albero dei processi, così come riportato dal comando
112 \label{fig:proc_tree}
115 Dato che tutti i processi attivi nel sistema sono comunque generati da
116 \cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
117 vero, in Linux ci sono alcuni processi speciali che pur comparendo come
118 figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
119 direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.).} si
120 possono classificare i processi con la relazione padre/figlio in
121 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
122 organizzati in un albero di directory (si veda
123 \secref{sec:file_organization}); in \figref{fig:proc_tree} si è mostrato il
124 risultato del comando \cmd{pstree} che permette di visualizzare questa
125 struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
128 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
129 \textit{process table}; per ciascun processo viene mantenuta una voce,
130 costituita da una struttura \struct{task\_struct}, nella tabella dei processi
131 che contiene tutte le informazioni rilevanti per quel processo. Tutte le
132 strutture usate a questo scopo sono dichiarate nell'header file
133 \file{linux/sched.h}, ed uno schema semplificato, che riporta la struttura
134 delle principali informazioni contenute nella \struct{task\_struct} (che in
135 seguito incontreremo a più riprese), è mostrato in
136 \figref{fig:proc_task_struct}.
140 \includegraphics[width=13cm]{img/task_struct}
141 \caption{Schema semplificato dell'architettura delle strutture usate dal
142 kernel nella gestione dei processi.}
143 \label{fig:proc_task_struct}
147 Come accennato in \secref{sec:intro_unix_struct} è lo
148 \textit{scheduler}\index{scheduler} che decide quale processo mettere in
149 esecuzione; esso viene eseguito ad ogni system call ed ad ogni
150 interrupt,\footnote{più in una serie di altre occasioni. NDT completare questa
151 parte.} (ma può essere anche attivato esplicitamente). Il timer di sistema
152 provvede comunque a che esso sia invocato periodicamente, generando un
153 interrupt periodico secondo la frequenza specificata dalla costante
154 \const{HZ}, definita in \file{asm/param.h}, ed il cui valore è espresso in
155 Hertz.\footnote{Il valore usuale di questa costante è 100, per tutte le
156 architetture eccetto l'alpha, per la quale è 1000. Occorre fare attenzione a
157 non confondere questo valore con quello dei clock tick (vedi
158 \secref{sec:sys_unix_time}).}
159 %Si ha cioè un interrupt dal timer ogni centesimo di secondo.
161 Ogni volta che viene eseguito, lo \textit{scheduler}\index{scheduler} effettua
162 il calcolo delle priorità dei vari processi attivi (torneremo su questo in
163 \secref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
164 esecuzione fino alla successiva invocazione.
167 \subsection{Una panoramica sulle funzioni fondamentali}
168 \label{sec:proc_handling_intro}
170 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
171 una system call, Linux però usa un'altra nomenclatura, e la funzione
172 \func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene
173 usata anche per generare i \textit{thread}. Il processo figlio creato dalla
174 \func{fork} è una copia identica del processo processo padre, ma ha un nuovo
175 \acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e
176 figlio sono affrontate in dettaglio in \secref{sec:proc_fork}).
178 Se si vuole che il processo padre si fermi fino alla conclusione del processo
179 figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
180 funzione \func{wait} o la funzione \func{waitpid} (si veda
181 \secref{sec:proc_wait}); queste funzioni restituiscono anche un'informazione
182 abbastanza limitata sulle cause della terminazione del processo figlio.
184 Quando un processo ha concluso il suo compito o ha incontrato un errore non
185 risolvibile esso può essere terminato con la funzione \func{exit} (si veda
186 quanto discusso in \secref{sec:proc_conclusion}). La vita del processo però
187 termina solo quando la notifica della sua conclusione viene ricevuta dal
188 processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
189 associate vengono rilasciate.
191 Avere due processi che eseguono esattamente lo stesso codice non è molto
192 utile, normalmente si genera un secondo processo per affidargli l'esecuzione
193 di un compito specifico (ad esempio gestire una connessione dopo che questa è
194 stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
195 quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
196 coi processi che è la \func{exec}.
198 Il programma che un processo sta eseguendo si chiama immagine del processo (o
199 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
200 caricare un altro programma da disco sostituendo quest'ultimo all'immagine
201 corrente; questo fa sì che l'immagine precedente venga completamente
202 cancellata. Questo significa che quando il nuovo programma termina, anche il
203 processo termina, e non si può tornare alla precedente immagine.
205 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
206 particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
207 prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
208 non ritorna mai (in quanto con essa viene eseguito un altro programma).
212 \section{Le funzioni di base}% della gestione dei processi}
213 \label{sec:proc_handling}
215 In questa sezione tratteremo le problematiche della gestione dei processi
216 all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con le
217 funzioni elementari che permettono di leggerne gli identificatori, per poi
218 passare alla spiegazione delle funzioni base che si usano per la creazione e
219 la terminazione dei processi, e per la messa in esecuzione degli altri
223 \subsection{Gli identificatori dei processi}
226 Come accennato nell'introduzione, ogni processo viene identificato dal sistema
227 da un numero identificativo univoco, il \textit{process ID} o \acr{pid};
228 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
229 intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
232 Il \acr{pid} viene assegnato in forma progressiva\footnote{in genere viene
233 assegnato il numero successivo a quello usato per l'ultimo processo creato,
234 a meno che questo numero non sia già utilizzato per un altro \acr{pid},
235 \acr{pgid} o \acr{sid} (vedi \secref{sec:sess_proc_group}).} ogni volta che
236 un nuovo processo viene creato, fino ad un limite che, essendo il \acr{pid} un
237 numero positivo memorizzato in un intero a 16 bit, arriva ad un massimo di
238 32768. Oltre questo valore l'assegnazione riparte dal numero più basso
239 disponibile a partire da un minimo di 300,\footnote{questi valori, fino al
240 kernel 2.4.x, sono definiti dalla macro \const{PID\_MAX} in \file{threads.h}
241 e direttamente in \file{fork.c}, con il kernel 2.5.x e la nuova interfaccia
242 per i thread creata da Ingo Molnar anche il meccanismo di allocazione dei
243 \acr{pid} è stato modificato.} che serve a riservare i \acr{pid} più bassi
244 ai processi eseguiti direttamente dal kernel. Per questo motivo, come visto
245 in \secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il
246 \acr{pid} uguale a uno.
248 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
249 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
250 \textit{parent process ID}). Questi due identificativi possono essere
251 ottenuti usando le due funzioni \funcd{getpid} e \funcd{getppid}, i cui
254 \headdecl{sys/types.h}
256 \funcdecl{pid\_t getpid(void)}
258 Restituisce il \acr{pid} del processo corrente.
260 \funcdecl{pid\_t getppid(void)}
262 Restituisce il \acr{pid} del padre del processo corrente.
264 \bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
266 \noindent esempi dell'uso di queste funzioni sono riportati in
267 \figref{fig:proc_fork_code}, nel programma \file{ForkTest.c}.
269 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
270 candidato per generare ulteriori indicatori associati al processo di cui
271 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
272 funzione \func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid}
273 per generare un pathname univoco, che non potrà essere replicato da un altro
274 processo che usi la stessa funzione.
276 Tutti i processi figli dello stesso processo padre sono detti
277 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
278 sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
279 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
280 \secref{cha:session}, dove esamineremo gli altri identificativi associati ad
281 un processo e le varie relazioni fra processi utilizzate per definire una
284 Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
285 \secref{sec:sess_proc_group}, relativi al controllo di sessione), ad ogni
286 processo vengono associati degli altri identificatori che vengono usati per il
287 controllo di accesso. Questi servono per determinare se un processo può
288 eseguire o meno le operazioni richieste, a seconda dei privilegi e
289 dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
290 affrontato in dettaglio in \secref{sec:proc_perms}.
293 \subsection{La funzione \func{fork}}
294 \label{sec:proc_fork}
296 La funzione \funcd{fork} è la funzione fondamentale della gestione dei
297 processi: come si è detto l'unico modo di creare un nuovo processo è
298 attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
299 tutte le volte che si devono scrivere programmi che usano il multitasking. Il
300 prototipo della funzione è:
302 \headdecl{sys/types.h}
304 \funcdecl{pid\_t fork(void)}
305 Crea un nuovo processo.
307 \bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
308 zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
309 errore; \var{errno} può assumere i valori:
311 \item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
312 processo (per allocare la tabella delle pagine e le strutture del task) o
313 si è esaurito il numero di processi disponibili.
314 \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
315 strutture necessarie al kernel per creare il nuovo processo.
319 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
320 il processo figlio continuano ad essere eseguiti normalmente a partire
321 dall'istruzione successiva alla \func{fork}; il processo figlio è però una
322 copia del padre, e riceve una copia dei segmenti di testo, stack e dati (vedi
323 \secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
324 padre. Si tenga presente però che la memoria è copiata, non condivisa,
325 pertanto padre e figlio vedono variabili diverse.
327 Per quanto riguarda la gestione della memoria, in generale il segmento di
328 testo, che è identico per i due processi, è condiviso e tenuto in read-only
329 per il padre e per i figli. Per gli altri segmenti Linux utilizza la tecnica
330 del \textit{copy on write}\index{copy on write}; questa tecnica comporta che
331 una pagina di memoria viene effettivamente copiata per il nuovo processo solo
332 quando ci viene effettuata sopra una scrittura (e si ha quindi una reale
333 differenza fra padre e figlio). In questo modo si rende molto più efficiente
334 il meccanismo della creazione di un nuovo processo, non essendo più necessaria
335 la copia di tutto lo spazio degli indirizzi virtuali del padre, ma solo delle
336 pagine di memoria che sono state modificate, e solo al momento della modifica
339 La differenza che si ha nei due processi è che nel processo padre il valore di
340 ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
341 nel figlio è zero; in questo modo il programma può identificare se viene
342 eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
343 \textbf{due} volte: una nel padre e una nel figlio.
345 La scelta di questi valori di ritorno non è casuale, un processo infatti può
346 avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
347 permette di identificare quello appena creato; al contrario un figlio ha
348 sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
349 \func{getppid}, vedi \secref{sec:proc_pid}) per cui si usa il valore nullo,
350 che non è il \acr{pid} di nessun processo.
353 \footnotesize \centering
354 \begin{minipage}[c]{15cm}
355 \includecodesample{listati/ForkTest.c}
358 \caption{Esempio di codice per la creazione di nuovi processi.}
359 \label{fig:proc_fork_code}
362 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
363 sono già troppi processi nel sistema (il che di solito è sintomo che
364 qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
365 sul numero totale di processi permessi all'utente (vedi
366 \secref{sec:sys_resource_limit}, ed in particolare
367 \tabref{tab:sys_rlimit_values}).
369 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
370 quella in cui all'interno di un programma si creano processi figli cui viene
371 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
372 ne esegue un'altra. È il caso tipico dei programmi server (il modello
373 \textit{client-server} è illustrato in \secref{sec:net_cliserv}) in cui il
374 padre riceve ed accetta le richieste da parte dei programmi client, per
375 ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
378 La seconda modalità è quella in cui il processo vuole eseguire un altro
379 programma; questo è ad esempio il caso della shell. In questo caso il processo
380 crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
381 cui parleremo in \secref{sec:proc_exec}) subito dopo la \func{fork}.
383 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
384 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
385 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
386 scelto di mantenere questa separazione, dato che, come per la prima modalità
387 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
388 aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
389 seconda modalità d'uso, avere le due funzioni separate permette al figlio di
390 cambiare gli attributi del processo (maschera dei segnali, redirezione
391 dell'output, identificatori) prima della \func{exec}, rendendo così
392 relativamente facile intervenire sulle le modalità di esecuzione del nuovo
395 In \figref{fig:proc_fork_code} è riportato il corpo del codice del programma
396 di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
397 dell'uso della funzione \func{fork}. Il programma crea un numero di figli
398 specificato da linea di comando, e prende anche alcune opzioni per indicare
399 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
400 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
401 descrizione delle opzioni); il codice completo, compresa la parte che gestisce
402 le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
403 distribuito insieme agli altri sorgenti degli esempi su
404 \href{http://gapil.firenze.linux.it/gapil_source.tgz}
405 {\texttt{http://gapil.firenze.linux.it/gapil\_source.tgz}}.
407 Decifrato il numero di figli da creare, il ciclo principale del programma
408 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
409 controllando il successo della chiamata a \func{fork} (\texttt{\small
410 25--29}); ciascun figlio (\texttt{\small 31--34}) si limita a stampare il
411 suo numero di successione, eventualmente attendere il numero di secondi
412 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
413 (\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
414 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
415 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
418 Se eseguiamo il comando\footnote{che è preceduto dall'istruzione \code{export
419 LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche.}
420 senza specificare attese (come si può notare in (\texttt{\small 17--19}) i
421 valori predefiniti specificano di non attendere), otterremo come output sul
426 [piccardi@selidor sources]$ export LD_LIBRARY_PATH=./; ./forktest 3
427 Process 1963: forking 3 child
428 Spawned 1 child, pid 1964
429 Child 1 successfully executing
430 Child 1, parent 1963, exiting
432 Spawned 2 child, pid 1965
433 Child 2 successfully executing
434 Child 2, parent 1963, exiting
436 Child 3 successfully executing
437 Child 3, parent 1963, exiting
438 Spawned 3 child, pid 1966
443 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
444 si può dire quale processo fra il padre ed il figlio venga eseguito per
445 primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo
446 scheduler\index{scheduler} di Ingo Molnar che esegue sempre per primo il
447 figlio; per mantenere la portabilità è opportuno non fare comunque
448 affidamento su questo comportamento.} dopo la chiamata a \func{fork};
449 dall'esempio si può notare infatti come nei primi due cicli sia stato eseguito
450 per primo il padre (con la stampa del \acr{pid} del nuovo processo) per poi
451 passare all'esecuzione del figlio (completata con i due avvisi di esecuzione
452 ed uscita), e tornare all'esecuzione del padre (con la stampa del passaggio al
453 ciclo successivo), mentre la terza volta è stato prima eseguito il figlio
454 (fino alla conclusione) e poi il padre.
456 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
457 scheduling usato dal kernel, dalla particolare situazione in cui si trova la
458 macchina al momento della chiamata, risultando del tutto impredicibile.
459 Eseguendo più volte il programma di prova e producendo un numero diverso di
460 figli, si sono ottenute situazioni completamente diverse, compreso il caso in
461 cui il processo padre ha eseguito più di una \func{fork} prima che uno dei
462 figli venisse messo in esecuzione.
464 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
465 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
466 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
467 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
468 rischio di incorrere nelle cosiddette
469 \textit{race condition}\index{race condition}
470 (vedi \secref{sec:proc_race_cond}).
472 Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
473 processi completamente separati, le modifiche delle variabili nei processi
474 figli (come l'incremento di \var{i} in \texttt{\small 31}) sono visibili solo
475 a loro (ogni processo vede solo la propria copia della memoria), e non hanno
476 alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
477 in eventuali altri processi figli che eseguano lo stesso codice).
479 Un secondo aspetto molto importante nella creazione dei processi figli è
480 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
481 proviamo a redirigere su un file l'output del nostro programma di test, quello
486 [piccardi@selidor sources]$ ./forktest 3 > output
487 [piccardi@selidor sources]$ cat output
488 Process 1967: forking 3 child
489 Child 1 successfully executing
490 Child 1, parent 1967, exiting
491 Test for forking 3 child
492 Spawned 1 child, pid 1968
494 Child 2 successfully executing
495 Child 2, parent 1967, exiting
496 Test for forking 3 child
497 Spawned 1 child, pid 1968
499 Spawned 2 child, pid 1969
501 Child 3 successfully executing
502 Child 3, parent 1967, exiting
503 Test for forking 3 child
504 Spawned 1 child, pid 1968
506 Spawned 2 child, pid 1969
508 Spawned 3 child, pid 1970
512 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
514 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
515 in gran dettaglio in \capref{cha:file_unix_interface} e in
516 \secref{cha:files_std_interface}. Qui basta accennare che si sono usate le
517 funzioni standard della libreria del C che prevedono l'output bufferizzato; e
518 questa bufferizzazione (trattata in dettaglio in \secref{sec:file_buffering})
519 varia a seconda che si tratti di un file su disco (in cui il buffer viene
520 scaricato su disco solo quando necessario) o di un terminale (nel qual caso il
521 buffer viene scaricato ad ogni carattere di a capo).
523 Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
524 buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
525 l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
526 non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
527 ogni figlio riceve una copia della memoria del padre, esso riceverà anche
528 quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
529 padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
530 figlio, troveremo nel file anche tutto quello che il processo padre aveva
531 scritto prima della sua creazione. E alla fine del file (dato che in questo
532 caso il padre esce per ultimo) troveremo anche l'output completo del padre.
534 L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
535 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
536 solo processi diversi possono scrivere in contemporanea sullo stesso file
537 (l'argomento della condivisione dei file è trattato in dettaglio in
538 \secref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
539 le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
542 Quello che succede è che quando lo standard output del padre viene rediretto,
543 lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha
544 la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione
545 \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file
546 descriptor aperti nel padre, il che comporta che padre e figli condividono le
547 stesse voci della \textit{file table} (per la spiegazione di questi termini si
548 veda \secref{sec:file_sharing}) e fra cui c'è anche la posizione corrente nel
551 In questo modo se un processo scrive sul file aggiornerà la posizione corrente
552 sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
553 \textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
554 casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
555 file, che l'output successivo di un processo vada a sovrapporsi a quello dei
556 precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
557 perdute per via di una sovrascrittura.
559 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
560 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
561 scrivono sullo stesso file (un caso tipico è la shell quando lancia un
562 programma, il cui output va sullo standard output).
564 In questo modo, anche se l'output viene rediretto, il padre potrà sempre
565 continuare a scrivere in coda a quanto scritto dal figlio in maniera
566 automatica; se così non fosse ottenere questo comportamento sarebbe
567 estremamente complesso necessitando di una qualche forma di comunicazione fra
568 i due processi per far riprendere al padre la scrittura al punto giusto.
570 In generale comunque non è buona norma far scrivere più processi sullo stesso
571 file senza una qualche forma di sincronizzazione in quanto, come visto anche
572 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
573 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
574 i file dopo una \func{fork} sono sostanzialmente due:
576 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
577 è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
578 della posizione corrente dopo eventuali operazioni di lettura e scrittura
579 effettuate dal figlio è automatica.
580 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
581 ciascuno dei due processi deve chiudere i file che non gli servono una volta
582 che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
585 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
586 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
587 comune dopo l'esecuzione di una \func{fork} è la seguente:
589 \item i file aperti e gli eventuali flag di
590 \textit{close-on-exec}\index{close-on-exec} impostati (vedi
591 \secref{sec:proc_exec} e \secref{sec:file_fcntl}).
592 \item gli identificatori per il controllo di accesso: l'\textsl{user-ID
593 reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
594 \textsl{group-ID effettivo} ed i \textit{group-ID supplementari} (vedi
595 \secref{sec:proc_access_id}).
596 \item gli identificatori per il controllo di sessione: il \textit{process
597 group-ID} e il \textit{session id} ed il terminale di controllo (vedi
598 \secref{sec:sess_proc_group}).
599 \item la directory di lavoro e la directory radice (vedi
600 \secref{sec:file_work_dir} e \secref{sec:file_chroot}).
601 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
602 \item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigmask}) e le
603 azioni installate (vedi \secref{sec:sig_gen_beha}).
604 \item i segmenti di memoria condivisa agganciati al processo (vedi
605 \secref{sec:ipc_sysv_shm}).
606 \item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
607 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
609 le differenze fra padre e figlio dopo la \func{fork} invece sono:
611 \item il valore di ritorno di \func{fork}.
612 \item il \acr{pid} (\textit{process id}).
613 \item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
614 impostato al \acr{pid} del padre.
615 \item i valori dei tempi di esecuzione della struttura \struct{tms} (vedi
616 \secref{sec:sys_cpu_times}) che nel figlio sono posti a zero.
617 \item i \textit{lock} sui file (vedi \secref{sec:file_locking}), che non
618 vengono ereditati dal figlio.
619 \item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_gen_beha}), che
620 per il figlio vengono cancellati.
624 \subsection{La funzione \func{vfork}}
625 \label{sec:proc_vfork}
627 La funzione \func{vfork} è esattamente identica a \func{fork} ed ha la stessa
628 semantica e gli stessi errori; la sola differenza è che non viene creata la
629 tabella delle pagine né la struttura dei task per il nuovo processo. Il
630 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
631 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
632 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
633 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
635 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
636 \func{fork} comportava anche la copia completa del segmento dati del processo
637 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
638 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
639 venne introdotta in BSD per migliorare le prestazioni.
641 Dato che Linux supporta il \textit{copy on write}\index{copy on write} la
642 perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
643 funzione (che resta un caso speciale della system call \func{\_\_clone}), è
644 deprecato; per questo eviteremo di trattarla ulteriormente.
647 \subsection{La conclusione di un processo.}
648 \label{sec:proc_termination}
650 In \secref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
651 chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
652 con un sistema multitasking resta da affrontare l'argomento dal punto di vista
653 di come il sistema gestisce la conclusione dei processi.
655 Abbiamo visto in \secref{sec:proc_conclusion} le tre modalità con cui un
656 programma viene terminato in maniera normale: la chiamata di \func{exit} (che
657 esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
658 dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
659 chiamata ad \func{\_exit} (che passa direttamente alle operazioni di
660 terminazione del processo da parte del kernel).
662 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
663 modalità di conclusione anomala; queste sono in sostanza due: il programma può
664 chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
665 terminato da un segnale. In realtà anche la prima modalità si riconduce alla
666 seconda, dato che \func{abort} si limita a generare il segnale
669 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
670 comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
671 memoria che stava usando, e così via; l'elenco completo delle operazioni
672 eseguite alla chiusura di un processo è il seguente:
674 \item tutti i file descriptor sono chiusi.
675 \item viene memorizzato lo stato di terminazione del processo.
676 \item ad ogni processo figlio viene assegnato un nuovo padre (in genere
678 \item viene inviato il segnale \const{SIGCHLD} al processo padre (vedi
679 \secref{sec:sig_sigchld}).
680 \item se il processo è un leader di sessione ed il suo terminale di controllo
681 è quello della sessione viene mandato un segnale di \const{SIGHUP} a tutti i
682 processi del gruppo di foreground e il terminale di controllo viene
683 disconnesso (vedi \secref{sec:sess_ctrl_term}).
684 \item se la conclusione di un processo rende orfano un \textit{process
685 group} ciascun membro del gruppo viene bloccato, e poi gli vengono
686 inviati in successione i segnali \const{SIGHUP} e \const{SIGCONT}
687 (vedi ancora \secref{sec:sess_ctrl_term}).
690 Oltre queste operazioni è però necessario poter disporre di un meccanismo
691 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
692 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
693 scelto consiste nel riportare lo stato di terminazione (il cosiddetto
694 \textit{termination status}) al processo padre.
696 Nel caso di conclusione normale, abbiamo visto in \secref{sec:proc_conclusion}
697 che lo stato di uscita del processo viene caratterizzato tramite il valore del
698 cosiddetto \textit{exit status}, cioè il valore passato alle funzioni
699 \func{exit} o \func{\_exit} (o dal valore di ritorno per \func{main}). Ma se
700 il processo viene concluso in maniera anomala il programma non può specificare
701 nessun \textit{exit status}, ed è il kernel che deve generare autonomamente il
702 \textit{termination status} per indicare le ragioni della conclusione anomala.
704 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
705 quello che contraddistingue lo stato di chiusura del processo e viene
706 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
707 \secref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
708 il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
711 La scelta di riportare al padre lo stato di terminazione dei figli, pur
712 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
713 alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
714 che sia così alla sua conclusione, dato che il padre potrebbe essere già
715 terminato (si potrebbe avere cioè quello che si chiama un processo
718 Questa complicazione viene superata facendo in modo che il processo orfano
719 venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
720 termina, il kernel controlla se è il padre di altri processi in esecuzione: in
721 caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
722 con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
723 avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
724 cui riportare il suo stato di terminazione. Come verifica di questo
725 comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
726 ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
730 [piccardi@selidor sources]$ ./forktest -c2 3
731 Process 1972: forking 3 child
732 Spawned 1 child, pid 1973
733 Child 1 successfully executing
735 Spawned 2 child, pid 1974
736 Child 2 successfully executing
738 Child 3 successfully executing
739 Spawned 3 child, pid 1975
741 [piccardi@selidor sources]$ Child 3, parent 1, exiting
742 Child 2, parent 1, exiting
743 Child 1, parent 1, exiting
746 come si può notare in questo caso il processo padre si conclude prima dei
747 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
748 secondi dopo viene stampato a video anche l'output dei tre figli che
749 terminano, e come si può notare in questo caso, al contrario di quanto visto
750 in precedenza, essi riportano 1 come \acr{ppid}.
752 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
753 perché non è detto che il padre possa ricevere immediatamente lo stato di
754 terminazione, quindi il kernel deve comunque conservare una certa quantità di
755 informazioni riguardo ai processi che sta terminando.
757 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
758 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
759 dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di terminazione,
760 mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
761 processi che sono terminati, ma il cui stato di terminazione non è stato
762 ancora ricevuto dal padre sono chiamati \textit{zombie}\index{zombie}, essi
763 restano presenti nella tabella dei processi ed in genere possono essere
764 identificati dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella
765 colonna che ne indica lo stato (vedi \tabref{tab:proc_proc_states}). Quando il
766 padre effettuerà la lettura dello stato di uscita anche questa informazione,
767 non più necessaria, verrà scartata e la terminazione potrà dirsi completamente
770 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
771 condizione: lanciamo il comando \cmd{forktest} in background, indicando al
772 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
773 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
778 [piccardi@selidor sources]$ ps T
779 PID TTY STAT TIME COMMAND
780 419 pts/0 S 0:00 bash
781 568 pts/0 S 0:00 ./forktest -e10 3
782 569 pts/0 Z 0:00 [forktest <defunct>]
783 570 pts/0 Z 0:00 [forktest <defunct>]
784 571 pts/0 Z 0:00 [forktest <defunct>]
785 572 pts/0 R 0:00 ps T
787 \normalsize e come si vede, dato che non si è fatto nulla per riceverne lo
788 stato di terminazione, i tre processi figli sono ancora presenti pur essendosi
789 conclusi, con lo stato di zombie\index{zombie} e l'indicazione che sono stati
792 La possibilità di avere degli zombie\index{zombie} deve essere tenuta sempre
793 presente quando si scrive un programma che deve essere mantenuto in esecuzione
794 a lungo e creare molti figli. In questo caso si deve sempre avere cura di far
795 leggere l'eventuale stato di uscita di tutti i figli (in genere questo si fa
796 attraverso un apposito \textit{signal handler}, che chiama la funzione
797 \func{wait}, vedi \secref{sec:sig_sigchld} e \secref{sec:proc_wait}). Questa
798 operazione è necessaria perché anche se gli \textit{zombie}\index{zombie} non
799 consumano risorse di memoria o processore, occupano comunque una voce nella
800 tabella dei processi, che a lungo andare potrebbe esaurirsi.
802 Si noti che quando un processo adottato da \cmd{init} termina, esso non
803 diviene uno \textit{zombie}\index{zombie}; questo perché una delle funzioni di
804 \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i processi
805 cui fa da padre, completandone la terminazione. Questo è quanto avviene anche
806 quando, come nel caso del precedente esempio con \cmd{forktest}, il padre
807 termina con dei figli in stato di zombie\index{zombie}: alla sua terminazione
808 infatti tutti i suoi figli (compresi gli zombie\index{zombie}) verranno
809 adottati da \cmd{init}, il quale provvederà a completarne la terminazione.
811 Si tenga presente infine che siccome gli zombie\index{zombie} sono processi
812 già usciti, non c'è modo di eliminarli con il comando \cmd{kill}; l'unica
813 possibilità di cancellarli dalla tabella dei processi è quella di terminare il
814 processo che li ha generati, in modo che \cmd{init} possa adottarli e
815 provvedere a concluderne la terminazione.
818 \subsection{Le funzioni \func{wait} e \func{waitpid}}
819 \label{sec:proc_wait}
821 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
822 consiste nella creazione di programmi di tipo server, in cui un processo
823 principale attende le richieste che vengono poi soddisfatte da una serie di
824 processi figli. Si è già sottolineato al paragrafo precedente come in questo
825 caso diventi necessario gestire esplicitamente la conclusione dei figli onde
826 evitare di riempire di \textit{zombie}\index{zombie} la tabella dei processi;
827 le funzioni deputate a questo compito sono sostanzialmente due, \funcd{wait} e
828 \func{waitpid}. La prima, il cui prototipo è:
830 \headdecl{sys/types.h}
831 \headdecl{sys/wait.h}
832 \funcdecl{pid\_t wait(int *status)}
834 Sospende il processo corrente finché un figlio non è uscito, o finché un
835 segnale termina il processo o chiama una funzione di gestione.
837 \bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
838 e -1 in caso di errore; \var{errno} può assumere i valori:
840 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
844 è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
845 processo figlio termina. Se un figlio è già terminato la funzione ritorna
846 immediatamente, se più di un figlio è terminato occorre chiamare la funzione
847 più volte se si vuole recuperare lo stato di terminazione di tutti quanti.
849 Al ritorno della funzione lo stato di terminazione del figlio viene salvato
850 nella variabile puntata da \param{status} e tutte le risorse del kernel
851 relative al processo (vedi \secref{sec:proc_termination}) vengono rilasciate.
852 Nel caso un processo abbia più figli il valore di ritorno (il \acr{pid} del
853 figlio) permette di identificare qual'è quello che è uscito.
855 Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
856 all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
857 necessario attendere la conclusione di un processo specifico occorrerebbe
858 predisporre un meccanismo che tenga conto dei processi già terminati, e
859 provvedere a ripetere la chiamata alla funzione nel caso il processo cercato
862 Per questo motivo lo standard POSIX.1 ha introdotto la funzione
863 \funcd{waitpid} che effettua lo stesso servizio, ma dispone di una serie di
864 funzionalità più ampie, legate anche al controllo di sessione (si veda
865 \secref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
866 comportamento di \func{wait} si consiglia di utilizzare sempre questa
867 funzione, il cui prototipo è:
869 \headdecl{sys/types.h}
870 \headdecl{sys/wait.h}
871 \funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
872 Attende la conclusione di un processo figlio.
874 \bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
875 è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e
876 -1 per un errore, nel qual caso \var{errno} assumerà i valori:
878 \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
879 la funzione è stata interrotta da un segnale.
880 \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
881 non è figlio del processo chiamante.
885 Le differenze principali fra le due funzioni sono che \func{wait} si blocca
886 sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la
887 possibilità si specificare un'opzione \const{WNOHANG} che ne previene il
888 blocco; inoltre \func{waitpid} può specificare in maniera flessibile quale
889 processo attendere, sulla base del valore fornito dall'argomento \param{pid},
890 secondo lo specchietto riportato in \tabref{tab:proc_waidpid_pid}.
895 \begin{tabular}[c]{|c|c|p{8cm}|}
897 \textbf{Valore} & \textbf{Opzione} &\textbf{Significato}\\
900 $<-1$& -- & attende per un figlio il cui \textit{process group} (vedi
901 \secref{sec:sess_proc_group}) è uguale al
902 valore assoluto di \param{pid}. \\
903 $-1$ & \const{WAIT\_ANY} & attende per un figlio qualsiasi, usata in
904 questa maniera è equivalente a \func{wait}.\\
905 $0$ & \const{WAIT\_MYPGRP} & attende per un figlio il cui \textit{process
906 group} è uguale a quello del processo chiamante. \\
907 $>0$ & -- &attende per un figlio il cui \acr{pid} è uguale al
908 valore di \param{pid}.\\
911 \caption{Significato dei valori dell'argomento \param{pid} della funzione
913 \label{tab:proc_waidpid_pid}
916 Il comportamento di \func{waitpid} può inoltre essere modificato passando
917 delle opportune opzioni tramite l'argomento \param{option}. I valori possibili
918 sono il già citato \const{WNOHANG}, che previene il blocco della funzione
919 quando il processo figlio non è terminato, e \const{WUNTRACED} che permette di
920 tracciare i processi bloccati. Il valore dell'opzione deve essere specificato
921 come maschera binaria ottenuta con l'OR delle suddette costanti con zero.
923 In genere si utilizza \const{WUNTRACED} all'interno del controllo di sessione,
924 (l'argomento è trattato in \secref{sec:sess_job_control}). In tal caso infatti
925 la funzione ritorna, restituendone il \acr{pid}, quando c'è un processo figlio
926 che è entrato in stato di sleep (vedi \tabref{tab:proc_proc_states}) e del
927 quale non si è ancora letto lo stato (con questa stessa opzione). In Linux
928 sono previste altre opzioni non standard relative al comportamento con i
929 thread, che riprenderemo in \secref{sec:thread_xxx}.
931 La terminazione di un processo figlio è chiaramente un evento asincrono
932 rispetto all'esecuzione di un programma e può avvenire in un qualunque
933 momento. Per questo motivo, come accennato nella sezione precedente, una delle
934 azioni prese dal kernel alla conclusione di un processo è quella di mandare un
935 segnale di \const{SIGCHLD} al padre. L'azione predefinita (si veda
936 \secref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
937 generazione costituisce il meccanismo di comunicazione asincrona con cui il
938 kernel avverte il processo padre che uno dei suoi figli è terminato.
940 In genere in un programma non si vuole essere forzati ad attendere la
941 conclusione di un processo per proseguire, specie se tutto questo serve solo
942 per leggerne lo stato di chiusura (ed evitare la presenza di
943 \textit{zombie}\index{zombie}), per questo la modalità più usata per chiamare
944 queste funzioni è quella di utilizzarle all'interno di un \textit{signal
945 handler} (vedremo un esempio di come gestire \const{SIGCHLD} con i segnali
946 in \secref{sec:sig_example}). In questo caso infatti, dato che il segnale è
947 generato dalla terminazione di un figlio, avremo la certezza che la chiamata a
948 \func{wait} non si bloccherà.
953 \begin{tabular}[c]{|c|p{10cm}|}
955 \textbf{Macro} & \textbf{Descrizione}\\
958 \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
959 figlio che sia terminato normalmente. \\
960 \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
961 stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
962 o come valore di ritorno di \func{main}). Può essere valutata solo se
963 \val{WIFEXITED} ha restituito un valore non nullo.\\
964 \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
965 in maniera anomala a causa di un segnale che non è stato catturato (vedi
966 \secref{sec:sig_notification}).\\
967 \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato
968 la terminazione anomala del processo. Può essere valutata solo se
969 \val{WIFSIGNALED} ha restituito un valore non nullo.\\
970 \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
971 file si \textit{core dump}. Può essere valutata solo se
972 \val{WIFSIGNALED} ha restituito un valore non nullo.\footnotemark \\
973 \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
974 \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
975 l'opzione \const{WUNTRACED}. \\
976 \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato
977 il processo, Può essere valutata solo se \val{WIFSTOPPED} ha
978 restituito un valore non nullo. \\
981 \caption{Descrizione delle varie macro di preprocessore utilizzabili per
982 verificare lo stato di terminazione \var{s} di un processo.}
983 \label{tab:proc_status_macro}
986 \footnotetext{questa macro non è definita dallo standard POSIX.1, ma è
987 presente come estensione sia in Linux che in altri Unix.}
989 Entrambe le funzioni di attesa restituiscono lo stato di terminazione del
990 processo tramite il puntatore \param{status} (se non interessa memorizzare lo
991 stato si può passare un puntatore nullo). Il valore restituito da entrambe le
992 funzioni dipende dall'implementazione, e tradizionalmente alcuni bit (in
993 genere 8) sono riservati per memorizzare lo stato di uscita, e altri per
994 indicare il segnale che ha causato la terminazione (in caso di conclusione
995 anomala), uno per indicare se è stato generato un core file, ecc.\footnote{le
996 definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
997 questo file non deve mai essere usato direttamente, esso viene incluso
998 attraverso \file{<sys/wait.h>}.}
1000 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
1001 analizzare lo stato di uscita. Esse sono definite sempre in
1002 \file{<sys/wait.h>} ed elencate in \tabref{tab:proc_status_macro} (si tenga
1003 presente che queste macro prendono come parametro la variabile di tipo
1004 \ctyp{int} puntata da \param{status}).
1006 Si tenga conto che nel caso di conclusione anomala il valore restituito da
1007 \val{WTERMSIG} può essere confrontato con le costanti definite in
1008 \file{signal.h} ed elencate in \tabref{tab:sig_signal_list}, e stampato usando
1009 le apposite funzioni trattate in \secref{sec:sig_strsignal}.
1012 \subsection{Le funzioni \func{wait3} e \func{wait4}}
1013 \label{sec:proc_wait4}
1015 Linux, seguendo un'estensione di BSD, supporta altre due funzioni per la
1016 lettura dello stato di terminazione di un processo, analoghe alle precedenti
1017 ma che prevedono un ulteriore parametro attraverso il quale il kernel può
1018 restituire al padre informazioni sulle risorse usate dal processo terminato e
1019 dai vari figli. Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che
1020 diventano accessibili definendo la macro \macro{\_USE\_BSD}; i loro prototipi
1023 \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
1024 \headdecl{sys/resource.h}
1026 \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
1028 È identica a \func{waitpid} sia per comportamento che per i valori dei
1029 parametri, ma restituisce in \param{rusage} un sommario delle risorse usate
1032 \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
1033 Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
1034 ormai deprecata in favore di \func{wait4}.
1037 la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene
1038 utilizzata anche dalla funzione \func{getrusage} (vedi
1039 \secref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
1040 processo; la sua definizione è riportata in \figref{fig:sys_rusage_struct}.
1043 \subsection{Le funzioni \func{exec}}
1044 \label{sec:proc_exec}
1046 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1047 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1048 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1049 processo chiama una di queste funzioni esso viene completamente sostituito dal
1050 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
1051 creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo
1052 heap, i dati ed il testo del processo corrente con un nuovo programma letto da
1055 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1056 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1057 (come mostrato in \figref{fig:proc_exec_relat}), sono tutte un front-end a
1058 \funcd{execve}. Il prototipo di quest'ultima è:
1059 \begin{prototype}{unistd.h}
1060 {int execve(const char *filename, char *const argv[], char *const envp[])}
1061 Esegue il programma contenuto nel file \param{filename}.
1063 \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
1064 qual caso \var{errno} può assumere i valori:
1066 \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è
1067 montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
1068 \item[\errcode{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente
1069 non è root, il processo viene tracciato, o il filesystem è montato con
1070 l'opzione \cmd{nosuid}.
1071 \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
1072 riconosciuto come tale, o compilato per un'altra architettura.
1073 \item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1074 necessari per eseguirlo non esistono.
1075 \item[\errcode{ETXTBSY}] L'eseguibile è aperto in scrittura da uno o più
1077 \item[\errcode{EINVAL}] L'eseguibile ELF ha più di un segmento
1078 \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
1080 \item[\errcode{ELIBBAD}] Un interprete ELF non è in un formato
1082 \item[\errcode{E2BIG}] La lista degli argomenti è troppo grande.
1084 ed inoltre anche \errval{EFAULT}, \errval{ENOMEM}, \errval{EIO},
1085 \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, \errval{ENFILE},
1089 La funzione \func{exec} esegue il file o lo script indicato da
1090 \param{filename}, passandogli la lista di argomenti indicata da \param{argv}
1091 e come ambiente la lista di stringhe indicata da \param{envp}; entrambe le
1092 liste devono essere terminate da un puntatore nullo. I vettori degli
1093 argomenti e dell'ambiente possono essere acceduti dal nuovo programma
1094 quando la sua funzione \func{main} è dichiarata nella forma
1095 \code{main(int argc, char *argv[], char *envp[])}.
1097 Le altre funzioni della famiglia servono per fornire all'utente una serie
1098 possibile di diverse interfacce per la creazione di un nuovo processo. I loro
1102 \funcdecl{int execl(const char *path, const char *arg, ...)}
1103 \funcdecl{int execv(const char *path, char *const argv[])}
1104 \funcdecl{int execle(const char *path, const char *arg, ..., char
1106 \funcdecl{int execlp(const char *file, const char *arg, ...)}
1107 \funcdecl{int execvp(const char *file, char *const argv[])}
1109 Sostituiscono l'immagine corrente del processo con quella indicata nel primo
1110 argomento. I parametri successivi consentono di specificare gli argomenti a
1111 linea di comando e l'ambiente ricevuti dal nuovo processo.
1113 \bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
1114 nel qual caso \var{errno} assumerà i valori visti in precedenza per
1118 Per capire meglio le differenze fra le funzioni della famiglia si può fare
1119 riferimento allo specchietto riportato in \tabref{tab:proc_exec_scheme}. La
1120 prima differenza riguarda le modalità di passaggio dei parametri che poi
1121 andranno a costituire gli argomenti a linea di comando (cioè i valori di
1122 \param{argv} e \param{argc} visti dalla funzione \func{main} del programma
1125 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
1126 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
1127 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
1128 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
1129 questo vettore \emph{deve} essere terminato da un puntatore nullo.
1131 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
1132 lista di puntatori, nella forma:
1133 \includecodesnip{listati/char_list.c}
1134 che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
1135 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1136 per indicare il nome del file che contiene il programma che verrà eseguito.
1141 \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1143 \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
1144 \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1146 &\func{execl}\texttt{ }&\func{execlp}&\func{execle}
1147 &\func{execv}\texttt{ }& \func{execvp}& \func{execve} \\
1150 argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
1151 argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
1153 filename completo &&$\bullet$&&&$\bullet$& \\
1154 ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
1156 ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
1157 uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1160 \caption{Confronto delle caratteristiche delle varie funzioni della
1161 famiglia \func{exec}.}
1162 \label{tab:proc_exec_scheme}
1165 La seconda differenza fra le funzioni riguarda le modalità con cui si
1166 specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
1167 indicano le due funzioni che replicano il comportamento della shell nello
1168 specificare il comando da eseguire; quando il parametro \param{file} non
1169 contiene una ``\file{/}'' esso viene considerato come un nome di programma, e
1170 viene eseguita automaticamente una ricerca fra i file presenti nella lista di
1171 directory specificate dalla variabile di ambiente \var{PATH}. Il file che
1172 viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1173 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1174 sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
1175 proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
1176 non viene trovato nessun altro file viene finalmente restituito
1179 Le altre quattro funzioni si limitano invece a cercare di eseguire il file
1180 indicato dall'argomento \param{path}, che viene interpretato come il
1181 \textit{pathname} del programma.
1185 \includegraphics[width=15cm]{img/exec_rel}
1186 \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1187 \label{fig:proc_exec_relat}
1190 La terza differenza è come viene passata la lista delle variabili di ambiente.
1191 Con lo mnemonico \code{e} vengono indicate quelle funzioni che necessitano di
1192 un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti
1193 a riga di comando (terminato quindi da un \val{NULL}), le altre usano il
1194 valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del
1195 processo di partenza per costruire l'ambiente.
1197 Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
1198 \func{exec} assume anche una serie di altre proprietà del processo chiamante;
1199 la lista completa è la seguente:
1201 \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
1203 \item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
1204 \textsl{group-ID supplementari} (vedi \secref{sec:proc_access_id}).
1205 \item il \textit{session id} (\acr{sid}) ed il \textit{process group-ID}
1206 (\acr{pgid}), vedi \secref{sec:sess_proc_group}.
1207 \item il terminale di controllo (vedi \secref{sec:sess_ctrl_term}).
1208 \item il tempo restante ad un allarme (vedi \secref{sec:sig_alarm_abort}).
1209 \item la directory radice e la directory di lavoro corrente (vedi
1210 \secref{sec:file_work_dir}).
1211 \item la maschera di creazione dei file (\var{umask}, vedi
1212 \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
1213 \secref{sec:file_locking}).
1214 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
1215 \secref{sec:sig_sigmask}).
1216 \item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
1217 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
1218 \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:sys_cpu_times}).
1221 Inoltre i segnali che sono stati impostati per essere ignorati nel processo
1222 chiamante mantengono la stessa impostazione pure nel nuovo programma, tutti
1223 gli altri segnali vengono impostati alla loro azione predefinita. Un caso
1224 speciale è il segnale \const{SIGCHLD} che, quando impostato a
1225 \const{SIG\_IGN}, può anche non essere reimpostato a \const{SIG\_DFL} (si veda
1226 \secref{sec:sig_gen_beha}).
1228 La gestione dei file aperti dipende dal valore che ha il flag di
1229 \textit{close-on-exec}\index{close-on-exec} (vedi anche
1230 \secref{sec:file_fcntl}) per ciascun file descriptor. I file per cui è
1231 impostato vengono chiusi, tutti gli altri file restano aperti. Questo
1232 significa che il comportamento predefinito è che i file restano aperti
1233 attraverso una \func{exec}, a meno di una chiamata esplicita a \func{fcntl}
1234 che imposti il suddetto flag.
1236 Per le directory, lo standard POSIX.1 richiede che esse vengano chiuse
1237 attraverso una \func{exec}, in genere questo è fatto dalla funzione
1238 \func{opendir} (vedi \secref{sec:file_dir_read}) che effettua da sola
1239 l'impostazione del flag di \textit{close-on-exec}\index{close-on-exec} sulle
1240 directory che apre, in maniera trasparente all'utente.
1242 Abbiamo detto che l'\textsl{user-ID reale} ed il \textsl{group-ID reale}
1243 restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
1244 l'\textsl{user-ID effettivo} ed il \textsl{group-ID effettivo} (il significato
1245 di questi identificatori è trattato in \secref{sec:proc_access_id}), tranne
1246 quando il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid}
1247 bit impostato, in questo caso l'\textsl{user-ID effettivo} ed il
1248 \textsl{group-ID effettivo} vengono impostati rispettivamente all'utente o al
1249 gruppo cui il file appartiene (per i dettagli vedi \secref{sec:proc_perms}).
1251 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1252 condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
1253 programma per caricare le librerie necessarie ed effettuare il link
1254 dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
1255 dinamiche viene usato l'interprete indicato nel segmento \const{PT\_INTERP},
1256 in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
1257 \acr{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
1258 \acr{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
1259 una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
1260 deve esse un programma valido (binario, non un altro script) che verrà
1261 chiamato come se si fosse eseguito il comando \cmd{interpreter [argomenti]
1264 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1265 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
1266 processo, con \func{exec} si lancia un nuovo programma, con \func{exit} e
1267 \func{wait} si effettua e verifica la conclusione dei processi. Tutte le
1268 altre funzioni sono ausiliarie e servono per la lettura e l'impostazione dei
1269 vari parametri connessi ai processi.
1273 \section{Il controllo di accesso}
1274 \label{sec:proc_perms}
1276 In questa sezione esamineremo le problematiche relative al controllo di
1277 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
1278 usati, come questi possono essere modificati nella creazione e nel lancio di
1279 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1280 problematiche connesse ad una gestione accorta dei privilegi.
1283 \subsection{Gli identificatori del controllo di accesso}
1284 \label{sec:proc_access_id}
1286 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
1287 realtà già esistono estensioni di questo modello base, che lo rendono più
1288 flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
1289 o il \textit{Mandatory Access Control} di SELinux; inoltre basandosi sul
1290 lavoro effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo
1291 sviluppo di una infrastruttura di sicurezza, il \textit{Linux Security
1292 Modules}, o LSM, in grado di fornire diversi agganci a livello del kernel
1293 per modularizzare tutti i possibili controlli di accesso.} di sicurezza di
1294 un sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
1295 separazione fra l'amministratore (\textsl{root}, detto spesso anche
1296 \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
1297 utenti, per i quali invece vengono effettuati i vari controlli di accesso.
1299 %Benché il sistema sia piuttosto semplice (è basato su un solo livello di
1300 % separazione) il sistema permette una
1301 %notevole flessibilità,
1303 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1304 identificatori univoci, lo user-ID ed il group-ID; questi servono al kernel per
1305 identificare uno specifico utente o un gruppo di utenti, per poi poter
1306 controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
1307 esempio in \secref{sec:file_access_control} vedremo come ad ogni file vengano
1308 associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
1309 appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
1310 kernel nella gestione dei permessi di accesso.
1312 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1313 evidente che per poter implementare un controllo sulle operazioni occorre
1314 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1315 anche a ciascun processo dovrà essere associato ad un utente e ad un gruppo.
1317 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1318 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1319 disporre di privilegi diversi, o dover impersonare un altro utente per un
1320 limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
1321 prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
1322 rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
1323 \textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il
1324 \textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di
1325 filesystem}), secondo la situazione illustrata in \tabref{tab:proc_uid_gid}.
1330 \begin{tabular}[c]{|c|c|l|p{7.3cm}|}
1332 \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
1333 & \textbf{Significato} \\
1336 \acr{uid} & \textit{real} & \textsl{user-ID reale}
1337 & indica l'utente che ha lanciato il programma\\
1338 \acr{gid} & '' &\textsl{group-ID reale}
1339 & indica il gruppo principale dell'utente che ha lanciato
1342 \acr{euid} & \textit{effective} &\textsl{user-ID effettivo}
1343 & indica l'utente usato nel controllo di accesso \\
1344 \acr{egid} & '' & \textsl{group-ID effettivo}
1345 & indica il gruppo usato nel controllo di accesso \\
1346 -- & -- & \textsl{group-ID supplementari}
1347 & indicano gli ulteriori gruppi cui l'utente appartiene \\
1349 -- & \textit{saved} & \textsl{user-ID salvato}
1350 & è una copia dell'\acr{euid} iniziale\\
1351 -- & '' & \textsl{group-ID salvato}
1352 & è una copia dell'\acr{egid} iniziale \\
1354 \acr{fsuid} & \textit{filesystem} &\textsl{user-ID di filesystem}
1355 & indica l'utente effettivo per l'accesso al filesystem \\
1356 \acr{fsgid} & '' & \textsl{group-ID di filesystem}
1357 & indica il gruppo effettivo per l'accesso al filesystem \\
1360 \caption{Identificatori di utente e gruppo associati a ciascun processo con
1361 indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
1362 \label{tab:proc_uid_gid}
1365 Al primo gruppo appartengono l'\textsl{user-ID reale} ed il \textsl{group-ID
1366 reale}: questi vengono impostati al login ai valori corrispondenti
1367 all'utente con cui si accede al sistema (e relativo gruppo principale).
1368 Servono per l'identificazione dell'utente e normalmente non vengono mai
1369 cambiati. In realtà vedremo (in \secref{sec:proc_setuid}) che è possibile
1370 modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
1371 questa possibilità è usata proprio dal programma \cmd{login} che, una volta
1372 completata la procedura di autenticazione, lancia una shell per la quale
1373 imposta questi identificatori ai valori corrispondenti all'utente che entra
1376 Al secondo gruppo appartengono lo \textsl{user-ID effettivo} ed il
1377 \textsl{group-ID effettivo} (a cui si aggiungono gli eventuali \textsl{group-ID
1378 supplementari} dei gruppi dei quali l'utente fa parte). Questi sono invece
1379 gli identificatori usati nella verifiche dei permessi del processo e per il
1380 controllo di accesso ai file (argomento affrontato in dettaglio in
1381 \secref{sec:file_perm_overview}).
1383 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1384 \textit{real} tranne nel caso in cui, come accennato in
1385 \secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
1386 \acr{suid} o \acr{sgid} impostati (il significato di questi bit è affrontato
1387 in dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno
1388 impostati all'utente e al gruppo proprietari del file. Questo consente, per
1389 programmi in cui ci sia necessità, di dare a qualunque utente normale
1390 privilegi o permessi di un altro (o dell'amministratore).
1392 Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi
1393 identificatori possono essere letti attraverso le rispettive funzioni:
1394 \funcd{getuid}, \funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, i loro
1398 \headdecl{sys/types.h}
1399 \funcdecl{uid\_t getuid(void)} Restituisce l'\textsl{user-ID reale} del
1402 \funcdecl{uid\_t geteuid(void)} Restituisce l'\textsl{user-ID effettivo} del
1405 \funcdecl{gid\_t getgid(void)} Restituisce il \textsl{group-ID reale} del
1408 \funcdecl{gid\_t getegid(void)} Restituisce il \textsl{group-ID effettivo}
1409 del processo corrente.
1411 \bodydesc{Queste funzioni non riportano condizioni di errore.}
1414 In generale l'uso di privilegi superiori deve essere limitato il più
1415 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1416 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1417 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1418 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1421 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
1422 \textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
1423 SVr4, e previsto dallo standard POSIX quando è definita la costante
1424 \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
1425 del programma su altri Unix è buona norma controllare sempre la
1426 disponibilità di queste funzioni controllando se questa costante è
1427 definita.} il secondo gruppo è specifico di Linux e viene usato per
1428 migliorare la sicurezza con NFS.
1430 L'\textsl{user-ID salvato} ed il \textsl{group-ID salvato} sono copie
1431 dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo} del processo
1432 padre, e vengono impostati dalla funzione \func{exec} all'avvio del processo,
1433 come copie dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo}
1434 dopo che questi sono stati impostati tenendo conto di eventuali \acr{suid} o
1435 \acr{sgid}. Essi quindi consentono di tenere traccia di quale fossero utente
1436 e gruppo effettivi all'inizio dell'esecuzione di un nuovo programma.
1438 L'\textsl{user-ID di filesystem} e il \textsl{group-ID di filesystem} sono
1439 un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
1440 (torneremo sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una
1441 replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
1442 quali si sostituiscono per tutte le operazioni di verifica dei permessi
1443 relativi ai file (trattate in \secref{sec:file_perm_overview}). Ogni
1444 cambiamento effettuato sugli identificatori effettivi viene automaticamente
1445 riportato su di essi, per cui in condizioni normali si può tranquillamente
1446 ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
1449 \subsection{Le funzioni \func{setuid} e \func{setgid}}
1450 \label{sec:proc_setuid}
1452 Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
1453 di appartenenza) ad un processo sono rispettivamente \funcd{setuid} e
1454 \funcd{setgid}; come accennato in \secref{sec:proc_access_id} in Linux esse
1455 seguono la semantica POSIX che prevede l'esistenza dell'\textit{user-ID
1456 salvato} e del \textit{group-ID salvato}; i loro prototipi sono:
1459 \headdecl{sys/types.h}
1461 \funcdecl{int setuid(uid\_t uid)} Imposta l'\textsl{user-ID} del processo
1464 \funcdecl{int setgid(gid\_t gid)} Imposta il \textsl{group-ID} del processo
1467 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1468 di fallimento: l'unico errore possibile è \errval{EPERM}.}
1471 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1472 la prima; la seconda si comporta esattamente allo stesso modo facendo
1473 riferimento al \textsl{group-ID} invece che all'\textsl{user-ID}. Gli
1474 eventuali \textsl{group-ID supplementari} non vengono modificati.
1476 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1477 l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di
1478 sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e
1479 \textit{saved}) vengono impostati al valore specificato da \param{uid},
1480 altrimenti viene impostato solo l'\textsl{user-ID effettivo}, e soltanto se il
1481 valore specificato corrisponde o all'\textsl{user-ID reale} o
1482 all'\textsl{user-ID salvato}. Negli altri casi viene segnalato un errore (con
1485 Come accennato l'uso principale di queste funzioni è quello di poter
1486 consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati (vedi
1487 \secref{sec:file_suid_sgid}) di riportare l'\textsl{user-ID effettivo} a quello
1488 dell'utente che ha lanciato il programma, effettuare il lavoro che non
1489 necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
1491 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1492 viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene
1493 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1494 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1495 falsificare la registrazione. Per questo motivo questo file (e l'analogo
1496 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
1497 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
1498 esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
1499 crea terminali multipli su una console) appartengono a questo gruppo ed hanno
1500 il bit \acr{sgid} impostato.
1502 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1503 situazione degli identificatori è la seguente:
1506 \textsl{group-ID reale} &=& \textrm{\acr{gid} (del chiamante)} \\
1507 \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
1508 \textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
1510 in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
1511 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo. A
1512 questo punto il programma può eseguire una \code{setgid(getgid())} per
1513 impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
1514 \textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
1515 non sarà possibile lanciare dal terminale programmi che modificano detto file,
1516 in tal caso infatti la situazione degli identificatori sarebbe:
1519 \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
1520 \textsl{group-ID effettivo} &=& \textrm{\acr{gid}} \\
1521 \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
1523 e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
1524 \textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
1525 aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
1526 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
1527 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
1528 in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
1529 funzione avrà successo e riporterà la situazione a:
1532 \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
1533 \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
1534 \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
1536 consentendo l'accesso a \file{/var/log/utmp}.
1538 Occorre però tenere conto che tutto questo non è possibile con un processo con
1539 i privilegi di amministratore, in tal caso infatti l'esecuzione di una
1540 \func{setuid} comporta il cambiamento di tutti gli identificatori associati al
1541 processo, rendendo impossibile riguadagnare i privilegi di amministratore.
1542 Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
1543 crea una nuova shell per l'utente; ma quando si vuole cambiare soltanto
1544 l'\textsl{user-ID effettivo} del processo per cedere i privilegi occorre
1545 ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
1548 \subsection{Le funzioni \func{setreuid} e \func{setregid}}
1549 \label{sec:proc_setreuid}
1551 Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non
1552 supportando\footnote{almeno fino alla versione 4.3+BSD TODO, FIXME verificare
1553 e aggiornare la nota.} gli identificatori del gruppo \textit{saved}, le usa
1554 per poter scambiare fra di loro \textit{effective} e \textit{real}. I
1555 rispettivi prototipi sono:
1558 \headdecl{sys/types.h}
1560 \funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Imposta l'\textsl{user-ID
1561 reale} e l'\textsl{user-ID effettivo} del processo corrente ai valori
1562 specificati da \param{ruid} e \param{euid}.
1564 \funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Imposta il \textsl{group-ID
1565 reale} ed il \textsl{group-ID effettivo} del processo corrente ai valori
1566 specificati da \param{rgid} e \param{egid}.
1568 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1569 di fallimento: l'unico errore possibile è \errval{EPERM}.}
1572 La due funzioni sono analoghe ed il loro comportamento è identico; quanto
1573 detto per la prima prima riguardo l'user-ID, si applica immediatamente alla
1574 seconda per il group-ID. I processi non privilegiati possono impostare solo i
1575 valori del loro user-ID effettivo o reale; valori diversi comportano il
1576 fallimento della chiamata; l'amministratore invece può specificare un valore
1577 qualunque. Specificando un argomento di valore -1 l'identificatore
1578 corrispondente verrà lasciato inalterato.
1580 Con queste funzioni si possono scambiare fra loro gli user-ID reale e
1581 effettivo, e pertanto è possibile implementare un comportamento simile a
1582 quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
1583 scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
1586 In questo caso però occorre porre molta attenzione quando si creano nuovi
1587 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
1588 questo caso infatti essi avranno un user-ID reale privilegiato, che dovrà
1589 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
1590 programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
1591 prima della \func{exec} per uniformare l'user-ID reale a quello effettivo) in
1592 caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio
1593 e riottenere privilegi non previsti.
1595 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
1596 si pone per l'user-ID salvato: questa funzione deriva da un'implementazione che
1597 non ne prevede la presenza, e quindi non è possibile usarla per correggere la
1598 situazione come nel caso precedente. Per questo motivo in Linux tutte le volte
1599 che si imposta un qualunque valore diverso da quello dall'user-ID reale
1600 corrente, l'user-ID salvato viene automaticamente uniformato al valore
1601 dell'user-ID effettivo.
1604 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
1605 \label{sec:proc_seteuid}
1607 Le due funzioni \funcd{seteuid} e \funcd{setegid} sono un'estensione allo
1608 standard POSIX.1 (ma sono comunque supportate dalla maggior parte degli Unix)
1609 e vengono usate per cambiare gli identificatori del gruppo \textit{effective};
1610 i loro prototipi sono:
1613 \headdecl{sys/types.h}
1615 \funcdecl{int seteuid(uid\_t uid)} Imposta l'user-ID effettivo del processo
1616 corrente a \param{uid}.
1618 \funcdecl{int setegid(gid\_t gid)} Imposta il group-ID effettivo del processo
1619 corrente a \param{gid}.
1621 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1622 di fallimento: l'unico errore è \errval{EPERM}.}
1625 Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo
1626 la prima. Gli utenti normali possono impostare l'user-ID effettivo solo al
1627 valore dell'user-ID reale o dell'user-ID salvato, l'amministratore può
1628 specificare qualunque valore. Queste funzioni sono usate per permettere
1629 all'amministratore di impostare solo l'user-ID effettivo, dato che l'uso
1630 normale di \func{setuid} comporta l'impostazione di tutti gli identificatori.
1633 \subsection{Le funzioni \func{setresuid} e \func{setresgid}}
1634 \label{sec:proc_setresuid}
1636 Le due funzioni \funcd{setresuid} e \funcd{setresgid} sono un'estensione
1637 introdotta in Linux,\footnote{a partire dal kernel 2.1.44.} e permettono un
1638 completo controllo su tutti e tre i gruppi di identificatori (\textit{real},
1639 \textit{effective} e \textit{saved}), i loro prototipi sono:
1642 \headdecl{sys/types.h}
1644 \funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Imposta
1645 l'user-ID reale, l'user-ID effettivo e l'user-ID salvato del processo corrente
1646 ai valori specificati rispettivamente da \param{ruid}, \param{euid} e
1649 \funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Imposta il
1650 group-ID reale, il group-ID effettivo ed il group-ID salvato del processo
1651 corrente ai valori specificati rispettivamente da \param{rgid}, \param{egid} e
1654 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1655 di fallimento: l'unico errore è \errval{EPERM}.}
1658 Le due funzioni sono identiche, quanto detto per la prima riguardo gli user-ID
1659 si applica alla seconda per i group-ID. I processi non privilegiati possono
1660 cambiare uno qualunque degli user-ID solo ad un valore corrispondente o
1661 all'user-ID reale, o a quello effettivo o a quello salvato, l'amministratore
1662 può specificare i valori che vuole; un valore di -1 per un qualunque parametro
1663 lascia inalterato l'identificatore corrispondente.
1665 Per queste funzioni esistono anche due controparti che permettono di leggere
1666 in blocco i vari identificatori: \funcd{getresuid} e \funcd{getresgid}; i loro
1670 \headdecl{sys/types.h}
1672 \funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge
1673 l'user-ID reale, l'user-ID effettivo e l'user-ID salvato del processo corrente.
1675 \funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
1676 group-ID reale, il group-ID effettivo e il group-ID salvato del processo
1679 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
1680 fallimento: l'unico errore possibile è \errval{EFAULT} se gli indirizzi delle
1681 variabili di ritorno non sono validi.}
1684 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
1685 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
1686 specificati come puntatori (è un altro esempio di \textit{value result
1687 argument}). Si noti che queste funzioni sono le uniche in grado di leggere
1688 gli identificatori del gruppo \textit{saved}.
1691 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
1692 \label{sec:proc_setfsuid}
1694 Queste funzioni servono per impostare gli identificatori del gruppo
1695 \textit{filesystem} che sono usati da Linux per il controllo dell'accesso ai
1696 file. Come già accennato in \secref{sec:proc_access_id} Linux definisce
1697 questo ulteriore gruppo di identificatori, che in circostanze normali sono
1698 assolutamente equivalenti a quelli del gruppo \textit{effective}, dato che
1699 ogni cambiamento di questi ultimi viene immediatamente riportato su di essi.
1701 C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
1702 identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
1703 ovviare ad un problema di sicurezza che si presenta quando si deve
1704 implementare un server NFS.
1706 Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
1707 file per assumere l'identità del singolo utente remoto, ma se questo viene
1708 fatto cambiando l'user-ID effettivo o l'user-ID reale il server si espone alla
1709 ricezione di eventuali segnali ostili da parte dell'utente di cui ha
1710 temporaneamente assunto l'identità. Cambiando solo l'user-ID di filesystem si
1711 ottengono i privilegi necessari per accedere ai file, mantenendo quelli
1712 originari per quanto riguarda tutti gli altri controlli di accesso, così che
1713 l'utente non possa inviare segnali al server NFS.
1715 Le due funzioni usate per cambiare questi identificatori sono \funcd{setfsuid}
1716 e \funcd{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
1717 usate se si intendono scrivere programmi portabili; i loro prototipi sono:
1719 \headdecl{sys/fsuid.h}
1721 \funcdecl{int setfsuid(uid\_t fsuid)} Imposta l'user-ID di filesystem del
1722 processo corrente a \param{fsuid}.
1724 \funcdecl{int setfsgid(gid\_t fsgid)} Imposta il group-ID di filesystem del
1725 processo corrente a \param{fsgid}.
1727 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1728 di fallimento: l'unico errore possibile è \errval{EPERM}.}
1730 \noindent queste funzioni hanno successo solo se il processo chiamante ha i
1731 privilegi di amministratore o, per gli altri utenti, se il valore specificato
1732 coincide con uno dei di quelli del gruppo \textit{real}, \textit{effective} o
1736 \subsection{Le funzioni \func{setgroups} e \func{getgroups}}
1737 \label{sec:proc_setgroups}
1739 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
1740 gruppi supplementari. Ogni processo può avere fino a \const{NGROUPS\_MAX}
1741 gruppi supplementari in aggiunta al gruppo primario, questi vengono ereditati
1742 dal processo padre e possono essere cambiati con queste funzioni.
1744 La funzione che permette di leggere i gruppi supplementari è
1745 \funcd{getgroups}; questa funzione è definita nello standard POSIX ed il suo
1748 \headdecl{sys/types.h}
1751 \funcdecl{int getgroups(int size, gid\_t list[])}
1753 Legge gli identificatori dei gruppi supplementari.
1755 \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
1756 successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
1759 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
1760 \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
1761 minore del numero di gruppi supplementari del processo.
1765 La funzione legge gli identificatori dei gruppi supplementari del processo sul
1766 vettore \param{list} di dimensione \param{size}. Non è specificato se la
1767 funzione inserisca o meno nella lista il group-ID effettivo del processo. Se si
1768 specifica un valore di \param{size} uguale a 0 \param{list} non viene
1769 modificato, ma si ottiene il numero di gruppi supplementari.
1771 Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
1772 ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è:
1774 \headdecl{sys/types.h}
1777 \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups,
1778 int *ngroups)} Legge i gruppi supplementari.
1780 \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori,
1781 restituisce 0 in caso di successo e -1 in caso di fallimento.}
1784 La funzione legge i gruppi supplementari dell'utente specificato da
1785 \param{user}, eseguendo una scansione del database dei gruppi (si veda
1786 \secref{sec:sys_user_group}). Ritorna poi in \param{groups} la lista di quelli
1787 a cui l'utente appartiene. Si noti che \param{ngroups} è passato come
1788 puntatore perché, qualora il valore specificato sia troppo piccolo, la
1789 funzione ritorna -1, passando indietro il numero dei gruppi trovati.
1791 Per impostare i gruppi supplementari di un processo ci sono due funzioni, che
1792 possono essere usate solo se si hanno i privilegi di amministratore. La prima
1793 delle due è \funcd{setgroups}, ed il suo prototipo è:
1795 \headdecl{sys/types.h}
1798 \funcdecl{int setgroups(size\_t size, gid\_t *list)}
1800 Imposta i gruppi supplementari del processo.
1802 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1803 fallimento, nel qual caso \var{errno} assumerà i valori:
1805 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
1806 \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
1807 \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
1812 La funzione imposta i gruppi supplementari del processo corrente ai valori
1813 specificati nel vettore passato con l'argomento \param{list}, di dimensioni
1814 date dall'argomento \param{size}. Il numero massimo di gruppi supplementari è
1815 un parametro di sistema, che può essere ricavato con le modalità spiegate in
1816 \secref{sec:sys_characteristics}.
1818 Se invece si vogliono impostare i gruppi supplementari del processo a quelli di
1819 un utente specifico, si può usare \funcd{initgroups} il cui prototipo è:
1821 \headdecl{sys/types.h}
1824 \funcdecl{int initgroups(const char *user, gid\_t group)}
1826 Inizializza la lista dei gruppi supplementari.
1828 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1829 fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
1830 \func{setgroups} più \errval{ENOMEM} quando non c'è memoria sufficiente
1831 per allocare lo spazio per informazioni dei gruppi.}
1834 La funzione esegue la scansione del database dei gruppi (usualmente
1835 \file{/etc/groups}) cercando i gruppi di cui è membro l'utente \param{user}
1836 con cui costruisce una lista di gruppi supplementari, a cui aggiunge anche
1837 \param{group}, infine imposta questa lista per il processo corrente usando
1838 \func{setgroups}. Si tenga presente che sia \func{setgroups} che
1839 \func{initgroups} non sono definite nello standard POSIX.1 e che pertanto non
1840 è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si
1841 compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole
1842 scrivere codice portabile.
1845 \section{La gestione della priorità di esecuzione}
1846 \label{sec:proc_priority}
1848 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
1849 lo \textit{scheduler}\index{scheduler} assegna la CPU ai vari processi attivi.
1850 In particolare prenderemo in esame i vari meccanismi con cui viene gestita
1851 l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di
1855 \subsection{I meccanismi di \textit{scheduling}}
1856 \label{sec:proc_sched}
1858 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
1859 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
1860 ed oggetto di numerose ricerche; in generale essa dipende in maniera
1861 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
1862 cui non esiste un meccanismo che sia valido per tutti gli usi.
1864 La caratteristica specifica di un sistema multitasking come Linux è quella del
1865 cosiddetto \textit{prehemptive multitasking}: questo significa che al
1866 contrario di altri sistemi (che usano invece il cosiddetto \textit{cooperative
1867 multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
1868 quando la CPU deve essere passata ad un altro processo. Come accennato in
1869 \secref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
1870 apposita del kernel, lo \textit{scheduler}\index{scheduler}, il cui scopo è
1871 quello di distribuire al meglio il tempo di CPU fra i vari processi.
1873 La cosa è resa ancora più complicata dal fatto che con le architetture
1874 multi-processore si deve anche scegliere quale sia la CPU più opportuna da
1875 utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
1876 rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
1877 un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
1878 banale.} Tutto questo comunque appartiene alle sottigliezze
1879 dell'implementazione del kernel; dal punto di vista dei programmi che girano
1880 in user space, anche quando si hanno più processori (e dei processi che sono
1881 eseguiti davvero in contemporanea), le politiche di scheduling riguardano
1882 semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui
1883 assegnazione sarà governata dai meccanismi di scelta delle priorità che
1884 restano gli stessi indipendentemente dal numero di processori.
1886 Si tenga conto poi che i processi non devono solo eseguire del codice: ad
1887 esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
1888 venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
1889 tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
1890 kernel provvedere a mettere in esecuzione un altro processo.
1892 Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
1893 processo, in Linux un processo può trovarsi in uno degli stati riportati in
1894 \tabref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
1895 \textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
1896 sia la sua priorità, un processo non potrà mai essere messo in esecuzione
1897 fintanto che esso si trova in uno qualunque degli altri stati.
1902 \begin{tabular}[c]{|p{2.8cm}|c|p{10cm}|}
1904 \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
1907 \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
1908 essere eseguito (cioè è in attesa che gli
1909 venga assegnata la CPU). \\
1910 \textbf{Sleep} & \texttt{S} & Il processo è in attesa di un
1911 risposta dal sistema, ma può essere
1912 interrotto da un segnale. \\
1913 \textbf{Uninterrutible Sleep}& \texttt{D} & Il processo è in
1914 attesa di un risposta dal sistema (in
1915 genere per I/O), e non può essere
1916 interrotto in nessuna circostanza. \\
1917 \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
1918 \const{SIGSTOP}, o è tracciato.\\
1919 \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
1920 suo stato di terminazione non è ancora
1921 stato letto dal padre. \\
1924 \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
1925 \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
1926 \cmd{ps} nell'omonimo campo.}
1927 \label{tab:proc_proc_states}
1930 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
1931 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
1932 dello scopo del programma non è detto neanche che sia la più importante (molti
1933 programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
1934 non è affatto detto che dare ad un programma la massima priorità di esecuzione
1935 abbia risultati significativi in termini di prestazioni.
1937 Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
1938 \secref{sec:proc_sched_stand}) è sempre stato basato su delle \textsl{priorità
1939 dinamiche}, in modo da assicurare che tutti i processi, anche i meno
1940 importanti, possano ricevere un po' di tempo di CPU. In sostanza quando un
1941 processo ottiene la CPU la sua priorità viene diminuita. In questo modo alla
1942 fine, anche un processo con priorità iniziale molto bassa, finisce per avere
1943 una priorità sufficiente per essere eseguito.
1945 Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
1946 assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
1947 alla normale priorità dinamica), per tenere conto dei sistemi
1948 real-time,\footnote{per sistema real-time si intende un sistema in grado di
1949 eseguire operazioni in un tempo ben determinato; in genere si tende a
1950 distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
1951 esecuzione di un programma siano determinabili con certezza assoluta (come
1952 nel caso di meccanismi di controllo di macchine, dove uno sforamento dei
1953 tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un
1954 occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
1955 processi che devono essere eseguiti in un determinato momento non debbano
1956 aspettare la conclusione di altri che non hanno questa necessità.
1958 Il concetto di priorità assoluta dice che quando due processi si contendono
1959 l'esecuzione, vince sempre quello con la priorità assoluta più alta.
1960 Ovviamente questo avviene solo per i processi che sono pronti per essere
1961 eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
1962 genere indicata con un numero intero, ed un valore più alto comporta una
1963 priorità maggiore. Su questa politica di scheduling torneremo in
1964 \secref{sec:proc_real_time}.
1966 In generale quello che succede in tutti gli Unix moderni è che ai processi
1967 normali viene sempre data una priorità assoluta pari a zero, e la decisione di
1968 assegnazione della CPU è fatta solo con il meccanismo tradizionale della
1969 priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
1970 assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
1971 priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
1975 \subsection{Il meccanismo di \textit{scheduling} standard}
1976 \label{sec:proc_sched_stand}
1978 A meno che non si abbiano esigenze specifiche, l'unico meccanismo di
1979 scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
1980 solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
1981 nella programmazione.
1983 Come accennato in Linux tutti i processi ordinari hanno la stessa priorità
1984 assoluta. Quello che determina quale, fra tutti i processi in attesa di
1985 esecuzione, sarà eseguito per primo, è la priorità dinamica, che è chiamata
1986 così proprio perché varia nel corso dell'esecuzione di un processo. Oltre a
1987 questo la priorità dinamica determina quanto a lungo un processo continuerà ad
1988 essere eseguito, e quando un processo potrà subentrare ad un altro
1991 Il meccanismo usato da Linux è piuttosto semplice, ad ogni processo è
1992 assegnata una \textit{time-slice}, cioè un intervallo di tempo (letteralmente
1993 una fetta) per il quale esso deve essere eseguito. Il valore della
1994 \textit{time-slice} è controllato dalla cosiddetta \textit{nice} (o
1995 \textit{niceness}) del processo. Essa è contenuta nel campo \var{nice} di
1996 \struct{task\_struct}; tutti i processi vengono creati con lo stesso valore,
1997 ed essa specifica il valore della durata iniziale della \textit{time-slice}
1998 che viene assegnato ad un altro campo della struttura (\var{counter}) quando
1999 il processo viene eseguito per la prima volta e diminuito progressivamente ad
2000 ogni interruzione del timer.
2002 Quando lo scheduler\index{scheduler} viene eseguito scandisce la coda dei
2003 processi in stato \textit{runnable} associando, sulla base del valore di
2004 \var{counter}, un peso a ciascun processo in attesa di esecuzione,\footnote{il
2005 calcolo del peso in realtà è un po' più complicato, ad esempio nei sistemi
2006 multiprocessore viene favorito un processo che è eseguito sulla stessa CPU,
2007 e a parità del valore di \var{counter} viene favorito chi ha una priorità
2008 più elevata.} chi ha il peso più alto verrà posto in esecuzione, ed il
2009 precedente processo sarà spostato in fondo alla coda. Dato che ad ogni
2010 interruzione del timer il valore di \var{counter} del processo corrente viene
2011 diminuito, questo assicura che anche i processi con priorità più bassa
2012 verranno messi in esecuzione.
2014 La priorità di un processo è così controllata attraverso il valore di
2015 \var{nice}, che stabilisce la durata della \textit{time-slice}; per il
2016 meccanismo appena descritto infatti un valore più lungo assicura una maggiore
2017 attribuzione di CPU. L'origine del nome di questo parametro sta nel fatto che
2018 generalmente questo viene usato per diminuire la priorità di un processo, come
2019 misura di cortesia nei confronti degli altri. I processi infatti vengono
2020 creati dal sistema con lo stesso valore di \var{nice} (nullo) e nessuno è
2021 privilegiato rispetto agli altri; il valore può essere modificato solo
2022 attraverso la funzione \funcd{nice}, il cui prototipo è:
2023 \begin{prototype}{unistd.h}
2025 Aumenta il valore di \var{nice} per il processo corrente.
2027 \bodydesc{La funzione ritorna zero in caso di successo e -1 in caso di
2028 errore, nel qual caso \var{errno} può assumere i valori:
2030 \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
2031 specificato un valore di \param{inc} negativo.
2035 L'argomento \param{inc} indica l'incremento del valore di \var{nice}:
2036 quest'ultimo può assumere valori compresi fra \const{PRIO\_MIN} e
2037 \const{PRIO\_MAX} (che nel caso di Linux sono $-19$ e $20$), ma per
2038 \param{inc} si può specificare un valore qualunque, positivo o negativo, ed il
2039 sistema provvederà a troncare il risultato nell'intervallo consentito. Valori
2040 positivi comportano maggiore \textit{cortesia} e cioè una diminuzione della
2041 priorità, ogni utente può solo innalzare il valore di un suo processo. Solo
2042 l'amministratore può specificare valori negativi che permettono di aumentare
2043 la priorità di un processo.
2045 In SUSv2 la funzione ritorna il nuovo valore di \var{nice}; Linux non segue
2046 questa convenzione, e per leggere il nuovo valore occorre invece usare la
2047 funzione \funcd{getpriority}, derivata da BSD, il cui prototipo è:
2048 \begin{prototype}{sys/resource.h}
2049 {int getpriority(int which, int who)}
2051 Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
2053 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2054 errore, nel qual caso \var{errno} può assumere i valori:
2056 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2057 \param{which} e \param{who}.
2058 \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
2061 \noindent (in vecchie versioni può essere necessario includere anche
2062 \file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
2063 librerie, ma è comunque utile per portabilità).
2065 La funzione permette di leggere la priorità di un processo, di un gruppo di
2066 processi (vedi \secref{sec:sess_proc_group}) o di un utente, a seconda del
2067 valore di \param{which}, secondo la legenda di \tabref{tab:proc_getpriority},
2068 specificando un corrispondente valore per \param{who}; un valore nullo di
2069 quest'ultimo indica il processo, il gruppo di processi o l'utente correnti.
2074 \begin{tabular}[c]{|c|c|l|}
2076 \param{which} & \param{who} & \textbf{Significato} \\
2079 \const{PRIO\_PROCESS} & \type{pid\_t} & processo \\
2080 \const{PRIO\_PRGR} & \type{pid\_t} & process group \\
2081 \const{PRIO\_USER} & \type{uid\_t} & utente \\
2084 \caption{Legenda del valore dell'argomento \param{which} e del tipo
2085 dell'argomento \param{who} delle funzioni \func{getpriority} e
2086 \func{setpriority} per le tre possibili scelte.}
2087 \label{tab:proc_getpriority}
2090 La funzione restituisce la priorità più alta (cioè il valore più basso) fra
2091 quelle dei processi specificati; dato che -1 è un valore possibile, per poter
2092 rilevare una condizione di errore è necessario cancellare sempre \var{errno}
2093 prima della chiamata alla funzione, per verificare che essa resti uguale a
2096 Analoga a \func{getpriority} la funzione \funcd{setpriority} permette di
2097 impostare la priorità di uno o più processi; il suo prototipo è:
2098 \begin{prototype}{sys/resource.h}
2099 {int setpriority(int which, int who, int prio)}
2100 Imposta la priorità per l'insieme dei processi specificati.
2102 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2103 errore, nel qual caso \var{errno} può assumere i valori:
2105 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2106 \param{which} e \param{who}.
2107 \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
2108 \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
2109 specificato un valore di \param{inc} negativo.
2110 \item[\errcode{EACCES}] un processo senza i privilegi di amministratore ha
2111 cercato di modificare la priorità di un processo di un altro utente.
2115 La funzione imposta la priorità al valore specificato da \param{prio} per
2116 tutti i processi indicati dagli argomenti \param{which} e \param{who}. La
2117 gestione dei permessi dipende dalle varie implementazioni; in Linux, secondo
2118 le specifiche dello standard SUSv3, e come avviene per tutti i sistemi che
2119 derivano da SysV, è richiesto che l'user-ID reale o effettivo del processo
2120 chiamante corrispondano al real user-ID (e solo quello) del processo di cui si
2121 vuole cambiare la priorità; per i sistemi derivati da BSD invece (SunOS,
2122 Ultrix, *BSD) la corrispondenza può essere anche con l'user-ID effettivo.
2126 \subsection{Il meccanismo di \textit{scheduling real-time}}
2127 \label{sec:proc_real_time}
2129 Come spiegato in \secref{sec:proc_sched} lo standard POSIX.1b ha introdotto le
2130 priorità assolute per permettere la gestione di processi real-time. In realtà
2131 nel caso di Linux non si tratta di un vero hard real-time, in quanto in
2132 presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
2133 processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
2134 siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
2135 ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
2136 interrupt vengono intercettati dall'interfaccia real-time (o nel caso di
2137 Adeos gestiti dalle code del nano-kernel), in modo da poterlo controllare
2138 direttamente qualora ci sia la necessità di avere un processo con priorità
2139 più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
2140 page fault\index{page fault} si possono avere ritardi non previsti. Se
2141 l'ultimo problema può essere aggirato attraverso l'uso delle funzioni di
2142 controllo della memoria virtuale (vedi \secref{sec:proc_mem_lock}), il primo
2143 non è superabile e può comportare ritardi non prevedibili riguardo ai tempi di
2144 esecuzione di qualunque processo.
2146 In ogni caso occorre usare le priorità assolute con molta attenzione: se si dà
2147 ad un processo una priorità assoluta e questo finisce in un loop infinito,
2148 nessun altro processo potrà essere eseguito, ed esso sarà mantenuto in
2149 esecuzione permanentemente assorbendo tutta la CPU e senza nessuna possibilità
2150 di riottenere l'accesso al sistema. Per questo motivo è sempre opportuno,
2151 quando si lavora con processi che usano priorità assolute, tenere attiva una
2152 shell cui si sia assegnata la massima priorità assoluta, in modo da poter
2153 essere comunque in grado di rientrare nel sistema.
2155 Quando c'è un processo con priorità assoluta lo scheduler\index{scheduler} lo
2156 metterà in esecuzione prima di ogni processo normale. In caso di più processi
2157 sarà eseguito per primo quello con priorità assoluta più alta. Quando ci sono
2158 più processi con la stessa priorità assoluta questi vengono tenuti in una coda
2159 e tocca al kernel decidere quale deve essere eseguito.
2161 Il meccanismo con cui vengono gestiti questi processi dipende dalla politica
2162 di scheduling che si è scelto; lo standard ne prevede due:
2163 \begin{basedescript}{\desclabelwidth{2cm}\desclabelstyle{\nextlinelabel}}
2164 \item[\textit{FIFO}] \textit{First In First Out}. Il processo viene eseguito
2165 fintanto che non cede volontariamente la CPU, si blocca, finisce o viene
2166 interrotto da un processo a priorità più alta.
2167 \item[\textit{RR}] \textit{Round Robin}. Ciascun processo viene eseguito a
2168 turno per un certo periodo di tempo (una \textit{time slice}). Solo i
2169 processi con la stessa priorità ed in stato \textit{runnable} entrano nel
2173 La funzione per impostare le politiche di scheduling (sia real-time che
2174 ordinarie) ed i relativi parametri è \funcd{sched\_setscheduler}; il suo
2176 \begin{prototype}{sched.h}
2177 {int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
2178 Imposta priorità e politica di scheduling.
2180 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso
2181 di errore, nel qual caso \var{errno} può assumere i valori:
2183 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2184 \item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
2185 relativo valore di \param{p} non è valido.
2186 \item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
2187 politica richiesta (vale solo per \const{SCHED\_FIFO} e
2192 La funzione esegue l'impostazione per il processo specificato dall'argomento
2193 \param{pid}; un valore nullo esegue l'impostazione per il processo corrente.
2194 Solo un processo con i privilegi di amministratore può impostare delle
2195 priorità assolute diverse da zero. La politica di scheduling è specificata
2196 dall'argomento \param{policy} i cui possibili valori sono riportati in
2197 \tabref{tab:proc_sched_policy}; un valore negativo per \param{policy} mantiene
2198 la politica di scheduling corrente.
2203 \begin{tabular}[c]{|c|l|}
2205 \textbf{Policy} & \textbf{Significato} \\
2208 \const{SCHED\_FIFO} & Scheduling real-time con politica \textit{FIFO} \\
2209 \const{SCHED\_RR} & Scheduling real-time con politica \textit{Round
2211 \const{SCHED\_OTHER}& Scheduling ordinario\\
2214 \caption{Valori dell'argomento \param{policy} per la funzione
2215 \func{sched\_setscheduler}. }
2216 \label{tab:proc_sched_policy}
2219 Il valore della priorità è passato attraverso la struttura
2220 \struct{sched\_param} (riportata in \figref{fig:sig_sched_param}), il cui solo
2221 campo attualmente definito è \var{sched\_priority}, che nel caso delle
2222 priorità assolute deve essere specificato nell'intervallo fra un valore
2223 massimo ed uno minimo, che nel caso sono rispettivamente 1 e 99 (il valore
2224 zero è legale, ma indica i processi normali).
2226 \begin{figure}[!htb]
2227 \footnotesize \centering
2228 \begin{minipage}[c]{15cm}
2229 \begin{lstlisting}[stepnumber=0]{}
2230 struct sched_param {
2236 \caption{La struttura \structd{sched\_param}.}
2237 \label{fig:sig_sched_param}
2240 Lo standard POSIX.1b prevede comunque che i due valori della massima e minima
2241 priorità statica possano essere ottenuti, per ciascuna delle politiche di
2242 scheduling realtime, tramite le due funzioni \funcd{sched\_get\_priority\_max}
2243 e \funcd{sched\_get\_priority\_min}, i cui prototipi sono:
2247 \funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
2248 massimo della priorità statica per la politica di scheduling \param{policy}.
2251 \funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
2252 della priorità statica per la politica di scheduling \param{policy}.
2254 \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
2255 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2257 \item[\errcode{EINVAL}] il valore di \param{policy} è invalido.
2262 I processi con politica di scheduling \const{SCHED\_OTHER} devono specificare
2263 un valore nullo (altrimenti si avrà un errore \errcode{EINVAL}), questo valore
2264 infatti non ha niente a che vedere con la priorità dinamica determinata dal
2265 valore di \var{nice}, che deve essere impostato con le funzioni viste in
2268 Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
2269 esegue sempre il primo della lista, mentre un nuovo processo che torna in
2270 stato \textit{runnable} viene sempre inserito in coda alla lista. Se la
2271 politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
2272 automaticamente rimesso in coda alla lista, e la sua esecuzione continua
2273 fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
2274 volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
2275 sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
2276 nel caso che esso sia stato interrotto da un processo a priorità più alta.
2278 La priorità assoluta può essere riletta indietro dalla funzione
2279 \funcd{sched\_getscheduler}, il cui prototipo è:
2280 \begin{prototype}{sched.h}
2281 {int sched\_getscheduler(pid\_t pid)}
2282 Legge la politica di scheduling per il processo \param{pid}.
2284 \bodydesc{La funzione ritorna la politica di scheduling in caso di successo
2285 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2287 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2288 \item[\errcode{EINVAL}] il valore di \param{pid} è negativo.
2292 La funzione restituisce il valore (secondo quanto elencato in
2293 \tabref{tab:proc_sched_policy}) della politica di scheduling per il processo
2294 specificato; se \param{pid} è nullo viene restituito quello del processo
2297 Se si intende operare solo sulla priorità assoluta di un processo si possono
2298 usare le funzioni \funcd{sched\_setparam} e \funcd{sched\_getparam}, i cui
2303 \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *p)}
2304 Imposta la priorità assoluta del processo \param{pid}.
2307 \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *p)}
2308 Legge la priorità assoluta del processo \param{pid}.
2310 \bodydesc{La funzione ritorna la priorità in caso di successo
2311 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2313 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2314 \item[\errcode{EINVAL}] il valore di \param{pid} è negativo.
2318 L'uso di \func{sched\_setparam} che è del tutto equivalente a
2319 \func{sched\_setscheduler} con \param{priority} uguale a -1. Come per
2320 \func{sched\_setscheduler} specificando 0 come valore di \param{pid} si opera
2321 sul processo corrente. La disponibilità di entrambe le funzioni può essere
2322 verificata controllando la macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è
2323 definita nell'header \file{sched.h}.
2325 L'ultima funzione che permette di leggere le informazioni relative ai processi
2326 real-time è \funcd{sched\_rr\_get\_interval}, che permette di ottenere la
2327 lunghezza della \textit{time slice} usata dalla politica \textit{round robin};
2329 \begin{prototype}{sched.h}
2330 {int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
2331 \param{tp} la durata della \textit{time slice} per il processo \param{pid}.
2333 \bodydesc{La funzione ritorna 0in caso di successo e -1 in caso di errore,
2334 nel qual caso \var{errno} può assumere i valori:
2336 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2337 \item[\errcode{ENOSYS}] la system call non è stata implementata.
2341 La funzione restituisce il valore dell'intervallo di tempo usato per la
2342 politica \textit{round robin} in una struttura \struct{timespec}, (la cui
2343 definizione si può trovare in \figref{fig:sys_timeval_struct}).
2346 Come accennato ogni processo che usa lo scheduling real-time può rilasciare
2347 volontariamente la CPU; questo viene fatto attraverso la funzione
2348 \funcd{sched\_yield}, il cui prototipo è:
2349 \begin{prototype}{sched.h}
2350 {int sched\_yield(void)}
2352 Rilascia volontariamente l'esecuzione.
2354 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
2355 nel qual caso \var{errno} viene impostata opportunamente.}
2358 La funzione fa sì che il processo rilasci la CPU, in modo da essere rimesso in
2359 coda alla lista dei processi da eseguire, e permettere l'esecuzione di un
2360 altro processo; se però il processo è l'unico ad essere presente sulla coda
2361 l'esecuzione non sarà interrotta. In genere usano questa funzione i processi
2362 in modalità \textit{fifo}, per permettere l'esecuzione degli altri processi
2363 con pari priorità quando la sezione più urgente è finita.
2366 \section{Problematiche di programmazione multitasking}
2367 \label{sec:proc_multi_prog}
2369 Benché i processi siano strutturati in modo da apparire il più possibile come
2370 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
2371 occorre tenere conto di una serie di problematiche che normalmente non
2372 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
2373 programma alla volta.
2375 Pur essendo questo argomento di carattere generale, ci è parso opportuno
2376 introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
2377 in capitoli successivi, in questa sezione conclusiva del capitolo in cui
2378 abbiamo affrontato la gestione dei processi.
2381 \subsection{Le operazioni atomiche}
2382 \label{sec:proc_atom_oper}
2384 La nozione di \textsl{operazione atomica} deriva dal significato greco della
2385 parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
2386 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
2387 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
2388 di interruzione in una fase intermedia.
2390 In un ambiente multitasking il concetto è essenziale, dato che un processo può
2391 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
2392 altro processo o dalla ricezione di un segnale; occorre pertanto essere
2393 accorti nei confronti delle possibili
2394 \textit{race condition}\index{race condition} (vedi
2395 \secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
2396 cui non erano ancora state completate.
2398 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
2399 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
2400 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
2401 \capref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
2402 \secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
2403 funzioni di libreria per compiere le operazioni necessarie è garanzia
2404 sufficiente di atomicità in quanto le system call con cui esse sono realizzate
2405 non possono essere interrotte (o subire interferenze pericolose) da altri
2408 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
2409 stesso processo, e pure alcune system call, possono essere interrotti in
2410 qualunque momento, e le operazioni di un eventuale \textit{signal handler}
2411 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
2412 il solo accesso o l'assegnazione di una variabile possono non essere più
2413 operazioni atomiche (torneremo su questi aspetti in
2414 \secref{sec:sig_control}).
2416 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
2417 il cui accesso è assicurato essere atomico. In pratica comunque si può
2418 assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
2419 \ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
2420 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
2421 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
2422 le strutture. In tutti questi casi è anche opportuno marcare come
2423 \direct{volatile} le variabili che possono essere interessate ad accesso
2424 condiviso, onde evitare problemi con le ottimizzazioni del codice.
2428 \subsection{Le \textit{race condition}\index{race condition} e i
2429 \textit{deadlock}\index{deadlock}}
2430 \label{sec:proc_race_cond}
2432 Si definiscono \textit{race condition}\index{race condition} tutte quelle
2433 situazioni in cui processi diversi operano su una risorsa comune, ed in cui il
2434 risultato viene a dipendere dall'ordine in cui essi effettuano le loro
2435 operazioni. Il caso tipico è quello di un'operazione che viene eseguita da un
2436 processo in più passi, e può essere compromessa dall'intervento di un altro
2437 processo che accede alla stessa risorsa quando ancora non tutti i passi sono
2440 Dato che in un sistema multitasking ogni processo può essere interrotto in
2441 qualunque momento per farne subentrare un altro in esecuzione, niente può
2442 assicurare un preciso ordine di esecuzione fra processi diversi o che una
2443 sezione di un programma possa essere eseguita senza interruzioni da parte di
2444 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
2445 difficili da tracciare, in quanto nella maggior parte dei casi tutto
2446 funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
2448 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
2449 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
2450 gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
2451 \textit{race condition}\index{race condition} si hanno quando diversi processi
2452 accedono allo stesso file, o nell'accesso a meccanismi di intercomunicazione
2453 come la memoria condivisa. In questi casi, se non si dispone della possibilità
2454 di eseguire atomicamente le operazioni necessarie, occorre che quelle parti di
2455 codice in cui si compiono le operazioni sulle risorse condivise (le cosiddette
2456 \textsl{sezioni critiche}\index{sezioni critiche}) del programma, siano
2457 opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
2458 problematiche di questo tipo in \capref{cha:IPC}).
2460 Un caso particolare di \textit{race condition}\index{race condition} sono poi
2461 i cosiddetti \textit{deadlock}\index{deadlock}, particolarmente gravi in
2462 quanto comportano spesso il blocco completo di un servizio, e non il
2463 fallimento di una singola operazione. Per definizione un
2464 \textit{deadlock}\index{deadlock} è una situazione in cui due o più processi
2465 non sono più in grado di proseguire perché ciascuno aspetta il risultato di
2466 una operazione che dovrebbe essere eseguita dall'altro.
2469 L'esempio tipico di una situazione che può condurre ad un
2470 \textit{deadlock}\index{deadlock} è quello in cui un flag di
2471 ``\textsl{occupazione}'' viene rilasciato da un evento asincrono (come un
2472 segnale o un altro processo) fra il momento in cui lo si è controllato
2473 (trovandolo occupato) e la successiva operazione di attesa per lo sblocco. In
2474 questo caso, dato che l'evento di sblocco del flag è avvenuto senza che ce ne
2475 accorgessimo proprio fra il controllo e la messa in attesa, quest'ultima
2476 diventerà perpetua (da cui il nome di \textit{deadlock}\index{deadlock}).
2478 In tutti questi casi è di fondamentale importanza il concetto di atomicità
2479 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
2480 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
2481 eseguire in maniera atomica le operazioni necessarie.
2484 \subsection{Le funzioni rientranti}
2485 \label{sec:proc_reentrant}
2487 Si dice \textsl{rientrante} una funzione che può essere interrotta in
2488 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
2489 un altro thread di esecuzione senza che questo comporti nessun problema
2490 nell'esecuzione della stessa. La problematica è comune nella programmazione
2491 multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare
2492 delle funzioni all'interno dei gestori dei segnali.
2494 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
2495 queste infatti vengono allocate nello stack, e un'altra invocazione non fa
2496 altro che allocarne un'altra copia. Una funzione può non essere rientrante
2497 quando opera su memoria che non è nello stack. Ad esempio una funzione non è
2498 mai rientrante se usa una variabile globale o statica.
2500 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
2501 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
2502 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
2503 esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
2504 potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
2505 Allo stesso modo una funzione può non essere rientrante se usa e modifica un
2506 oggetto che le viene fornito dal chiamante: due chiamate possono interferire
2507 se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
2508 parte del programmatore.
2510 In genere le funzioni di libreria non sono rientranti, molte di esse ad
2511 esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
2512 disposizione due macro di compilatore, \macro{\_REENTRANT} e
2513 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
2514 varie funzioni di libreria, che sono identificate aggiungendo il suffisso
2515 \code{\_r} al nome della versione normale.
2519 %%% Local Variables:
2521 %%% TeX-master: "gapil"