3 %% Copyright (C) 2000-2005 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 "Un preambolo",
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 sez.~\ref{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 sez.~\ref{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}, ecc.).} 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 sez.~\ref{sec:file_organization}); in fig.~\ref{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 fig.~\ref{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}
146 Come accennato in sez.~\ref{sec:intro_unix_struct} è lo
147 \textit{scheduler}\index{\textit{scheduler}} che decide quale processo mettere
148 in esecuzione; esso viene eseguito ad ogni system call ed ad ogni
149 interrupt,\footnote{più in una serie di altre occasioni. NDT completare questa
150 parte.} (ma può essere anche attivato esplicitamente). Il timer di sistema
151 provvede comunque a che esso sia invocato periodicamente, generando un
152 interrupt periodico secondo la frequenza specificata dalla costante
153 \const{HZ}, definita in \file{asm/param.h}, ed il cui valore è espresso in
154 Hertz.\footnote{Il valore usuale di questa costante è 100, per tutte le
155 architetture eccetto l'alpha, per la quale è 1000. Occorre fare attenzione a
156 non confondere questo valore con quello dei clock tick (vedi
157 sez.~\ref{sec:sys_unix_time}).}
158 %Si ha cioè un interrupt dal timer ogni centesimo di secondo.
160 Ogni volta che viene eseguito, lo \textit{scheduler}\index{\textit{scheduler}}
161 effettua il calcolo delle priorità dei vari processi attivi (torneremo su
162 questo in sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba
163 essere posto in esecuzione fino alla successiva invocazione.
166 \subsection{Una panoramica sulle funzioni fondamentali}
167 \label{sec:proc_handling_intro}
169 In un sistema unix-like i processi vengono sempre creati da altri processi
170 tramite la funzione \func{fork}; il nuovo processo (che viene chiamato
171 \textsl{figlio}) creato dalla \func{fork} è una copia identica del processo
172 processo originale (detto \textsl{padre}), ma ha un nuovo \acr{pid} e viene
173 eseguito in maniera indipendente (le differenze fra padre e figlio sono
174 affrontate in dettaglio in sez.~\ref{sec:proc_fork}).
176 Se si vuole che il processo padre si fermi fino alla conclusione del processo
177 figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
178 funzione \func{wait} o la funzione \func{waitpid} (si veda
179 sez.~\ref{sec:proc_wait}); queste funzioni restituiscono anche un'informazione
180 abbastanza limitata sulle cause della terminazione del processo figlio.
182 Quando un processo ha concluso il suo compito o ha incontrato un errore non
183 risolvibile esso può essere terminato con la funzione \func{exit} (si veda
184 quanto discusso in sez.~\ref{sec:proc_conclusion}). La vita del processo però
185 termina solo quando la notifica della sua conclusione viene ricevuta dal
186 processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
187 associate vengono rilasciate.
189 Avere due processi che eseguono esattamente lo stesso codice non è molto
190 utile, normalmente si genera un secondo processo per affidargli l'esecuzione
191 di un compito specifico (ad esempio gestire una connessione dopo che questa è
192 stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
193 quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
194 coi processi che è la \func{exec}.
196 Il programma che un processo sta eseguendo si chiama immagine del processo (o
197 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
198 caricare un altro programma da disco sostituendo quest'ultimo all'immagine
199 corrente; questo fa sì che l'immagine precedente venga completamente
200 cancellata. Questo significa che quando il nuovo programma termina, anche il
201 processo termina, e non si può tornare alla precedente immagine.
203 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
204 particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
205 prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
206 non ritorna mai (in quanto con essa viene eseguito un altro programma).
210 \section{Le funzioni di base}% della gestione dei processi}
211 \label{sec:proc_handling}
213 In questa sezione tratteremo le problematiche della gestione dei processi
214 all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con le
215 funzioni elementari che permettono di leggerne gli identificatori, per poi
216 passare alla spiegazione delle funzioni base che si usano per la creazione e
217 la terminazione dei processi, e per la messa in esecuzione degli altri
221 \subsection{Gli identificatori dei processi}
224 Come accennato nell'introduzione, ogni processo viene identificato dal sistema
225 da un numero identificativo univoco, il \textit{process ID} o \acr{pid};
226 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
227 intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
230 Il \acr{pid} viene assegnato in forma progressiva\footnote{in genere viene
231 assegnato il numero successivo a quello usato per l'ultimo processo creato,
232 a meno che questo numero non sia già utilizzato per un altro \acr{pid},
233 \acr{pgid} o \acr{sid} (vedi sez.~\ref{sec:sess_proc_group}).} ogni volta
234 che un nuovo processo viene creato, fino ad un limite che, essendo il
235 \acr{pid} un numero positivo memorizzato in un intero a 16 bit, arriva ad un
236 massimo di 32768. Oltre questo valore l'assegnazione riparte dal numero più
237 basso disponibile a partire da un minimo di 300,\footnote{questi valori, fino
238 al kernel 2.4.x, sono definiti dalla macro \const{PID\_MAX} in
239 \file{threads.h} e direttamente in \file{fork.c}, con il kernel 2.5.x e la
240 nuova interfaccia per i thread creata da Ingo Molnar anche il meccanismo di
241 allocazione dei \acr{pid} è stato modificato.} che serve a riservare i
242 \acr{pid} più bassi ai processi eseguiti direttamente dal kernel. Per questo
243 motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di avvio
244 (\cmd{init}) ha sempre il \acr{pid} uguale a uno.
246 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
247 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
248 \textit{parent process ID}). Questi due identificativi possono essere
249 ottenuti usando le due funzioni \funcd{getpid} e \funcd{getppid}, i cui
252 \headdecl{sys/types.h}
254 \funcdecl{pid\_t getpid(void)}
256 Restituisce il \acr{pid} del processo corrente.
258 \funcdecl{pid\_t getppid(void)}
260 Restituisce il \acr{pid} del padre del processo corrente.
262 \bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
264 \noindent esempi dell'uso di queste funzioni sono riportati in
265 fig.~\ref{fig:proc_fork_code}, nel programma \file{ForkTest.c}.
267 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
268 candidato per generare ulteriori indicatori associati al processo di cui
269 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
270 funzione \func{tmpname} (si veda sez.~\ref{sec:file_temp_file}) usa il
271 \acr{pid} per generare un \index{\textit{pathname}}\textit{pathname} univoco,
272 che non potrà essere replicato da un altro processo che usi la stessa
275 Tutti i processi figli dello stesso processo padre sono detti
276 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
277 sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
278 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
279 cap.~\ref{cha:session}, dove esamineremo gli altri identificativi associati ad
280 un processo e le varie relazioni fra processi utilizzate per definire una
283 Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
284 sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione), ad ogni
285 processo vengono associati degli altri identificatori che vengono usati per il
286 controllo di accesso. Questi servono per determinare se un processo può
287 eseguire o meno le operazioni richieste, a seconda dei privilegi e
288 dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
289 affrontato in dettaglio in sez.~\ref{sec:proc_perms}.
292 \subsection{La funzione \func{fork}}
293 \label{sec:proc_fork}
295 La funzione \funcd{fork} è la funzione fondamentale della gestione dei
296 processi: come si è detto l'unico modo di creare un nuovo processo è
297 attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
298 tutte le volte che si devono scrivere programmi che usano il multitasking. Il
299 prototipo della funzione è:
301 \headdecl{sys/types.h}
303 \funcdecl{pid\_t fork(void)}
304 Crea un nuovo processo.
306 \bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
307 zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
308 errore; \var{errno} può assumere i valori:
310 \item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
311 processo (per allocare la tabella delle pagine e le strutture del task) o
312 si è esaurito il numero di processi disponibili.
313 \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
314 strutture necessarie al kernel per creare il nuovo processo.
318 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
319 il processo figlio continuano ad essere eseguiti normalmente a partire
320 dall'istruzione successiva alla \func{fork}; il processo figlio è però una
321 copia del padre, e riceve una copia dei segmenti di testo, stack e dati (vedi
322 sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
323 padre. Si tenga presente però che la memoria è copiata, non condivisa,
324 pertanto padre e figlio vedono variabili diverse.
326 Per quanto riguarda la gestione della memoria, in generale il segmento di
327 testo, che è identico per i due processi, è condiviso e tenuto in read-only
328 per il padre e per i figli. Per gli altri segmenti Linux utilizza la tecnica
329 del \textit{copy on write}\index{\textit{copy~on~write}}; questa tecnica
330 comporta che una pagina di memoria viene effettivamente copiata per il nuovo
331 processo solo quando ci viene effettuata sopra una scrittura (e si ha quindi
332 una reale differenza fra padre e figlio). In questo modo si rende molto più
333 efficiente il meccanismo della creazione di un nuovo processo, non essendo più
334 necessaria la copia di tutto lo spazio degli indirizzi virtuali del padre, ma
335 solo delle pagine di memoria che sono state modificate, e solo al momento
336 della modifica stessa.
338 La differenza che si ha nei due processi è che nel processo padre il valore di
339 ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
340 nel figlio è zero; in questo modo il programma può identificare se viene
341 eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
342 \textbf{due} volte: una nel padre e una nel figlio.
344 La scelta di questi valori di ritorno non è casuale, un processo infatti può
345 avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
346 permette di identificare quello appena creato; al contrario un figlio ha
347 sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
348 \func{getppid}, vedi sez.~\ref{sec:proc_pid}) per cui si usa il valore nullo,
349 che non è il \acr{pid} di nessun processo.
352 \footnotesize \centering
353 \begin{minipage}[c]{15cm}
354 \includecodesample{listati/ForkTest.c}
357 \caption{Esempio di codice per la creazione di nuovi processi.}
358 \label{fig:proc_fork_code}
361 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
362 sono già troppi processi nel sistema (il che di solito è sintomo che
363 qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
364 sul numero totale di processi permessi all'utente (vedi
365 sez.~\ref{sec:sys_resource_limit}, ed in particolare
366 tab.~\ref{tab:sys_rlimit_values}).
368 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
369 quella in cui all'interno di un programma si creano processi figli cui viene
370 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
371 ne esegue un'altra. È il caso tipico dei programmi server (il modello
372 \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
373 padre riceve ed accetta le richieste da parte dei programmi client, per
374 ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
377 La seconda modalità è quella in cui il processo vuole eseguire un altro
378 programma; questo è ad esempio il caso della shell. In questo caso il processo
379 crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
380 cui parleremo in sez.~\ref{sec:proc_exec}) subito dopo la \func{fork}.
382 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
383 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
384 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
385 scelto di mantenere questa separazione, dato che, come per la prima modalità
386 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
387 aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
388 seconda modalità d'uso, avere le due funzioni separate permette al figlio di
389 cambiare gli attributi del processo (maschera dei segnali, redirezione
390 dell'output, identificatori) prima della \func{exec}, rendendo così
391 relativamente facile intervenire sulle le modalità di esecuzione del nuovo
394 In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
395 di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
396 dell'uso della funzione \func{fork}. Il programma crea un numero di figli
397 specificato da linea di comando, e prende anche alcune opzioni per indicare
398 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
399 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
400 descrizione delle opzioni); il codice completo, compresa la parte che gestisce
401 le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
402 distribuito insieme agli altri sorgenti degli esempi su
403 \href{http://gapil.truelite.it/gapil_source.tgz}
404 {\textsf{http://gapil.truelite.it/gapil\_source.tgz}}.
406 Decifrato il numero di figli da creare, il ciclo principale del programma
407 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
408 controllando il successo della chiamata a \func{fork} (\texttt{\small
409 25--29}); ciascun figlio (\texttt{\small 31--34}) si limita a stampare il
410 suo numero di successione, eventualmente attendere il numero di secondi
411 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
412 (\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
413 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
414 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
417 Se eseguiamo il comando\footnote{che è preceduto dall'istruzione \code{export
418 LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche.}
419 senza specificare attese (come si può notare in (\texttt{\small 17--19}) i
420 valori predefiniti specificano di non attendere), otterremo come output sul
425 [piccardi@selidor sources]$ export LD_LIBRARY_PATH=./; ./forktest 3
426 Process 1963: forking 3 child
427 Spawned 1 child, pid 1964
428 Child 1 successfully executing
429 Child 1, parent 1963, exiting
431 Spawned 2 child, pid 1965
432 Child 2 successfully executing
433 Child 2, parent 1963, exiting
435 Child 3 successfully executing
436 Child 3, parent 1963, exiting
437 Spawned 3 child, pid 1966
442 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
443 si può dire quale processo fra il padre ed il figlio venga eseguito per
444 primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo
445 scheduler\index{\textit{scheduler}} di Ingo Molnar che esegue sempre per
446 primo il figlio; per mantenere la portabilità è opportuno non fare comunque
447 affidamento su questo comportamento.} dopo la chiamata a \func{fork};
448 dall'esempio si può notare infatti come nei primi due cicli sia stato eseguito
449 per primo il padre (con la stampa del \acr{pid} del nuovo processo) per poi
450 passare all'esecuzione del figlio (completata con i due avvisi di esecuzione
451 ed uscita), e tornare all'esecuzione del padre (con la stampa del passaggio al
452 ciclo successivo), mentre la terza volta è stato prima eseguito il figlio
453 (fino alla conclusione) e poi il padre.
455 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
456 scheduling usato dal kernel, dalla particolare situazione in cui si trova la
457 macchina al momento della chiamata, risultando del tutto impredicibile.
458 Eseguendo più volte il programma di prova e producendo un numero diverso di
459 figli, si sono ottenute situazioni completamente diverse, compreso il caso in
460 cui il processo padre ha eseguito più di una \func{fork} prima che uno dei
461 figli venisse messo in esecuzione.
463 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
464 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
465 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
466 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
467 rischio di incorrere nelle cosiddette
468 \textit{race condition}\index{\textit{race~condition}}
469 (vedi sez.~\ref{sec:proc_race_cond}).
471 Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
472 processi completamente separati, le modifiche delle variabili nei processi
473 figli (come l'incremento di \var{i} in \texttt{\small 31}) sono visibili solo
474 a loro (ogni processo vede solo la propria copia della memoria), e non hanno
475 alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
476 in eventuali altri processi figli che eseguano lo stesso codice).
478 Un secondo aspetto molto importante nella creazione dei processi figli è
479 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
480 proviamo a redirigere su un file l'output del nostro programma di test, quello
485 [piccardi@selidor sources]$ ./forktest 3 > output
486 [piccardi@selidor sources]$ cat output
487 Process 1967: forking 3 child
488 Child 1 successfully executing
489 Child 1, parent 1967, exiting
490 Test for forking 3 child
491 Spawned 1 child, pid 1968
493 Child 2 successfully executing
494 Child 2, parent 1967, exiting
495 Test for forking 3 child
496 Spawned 1 child, pid 1968
498 Spawned 2 child, pid 1969
500 Child 3 successfully executing
501 Child 3, parent 1967, exiting
502 Test for forking 3 child
503 Spawned 1 child, pid 1968
505 Spawned 2 child, pid 1969
507 Spawned 3 child, pid 1970
511 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
513 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
514 in gran dettaglio in cap.~\ref{cha:file_unix_interface} e in
515 cap.~\ref{cha:files_std_interface}. Qui basta accennare che si sono usate le
516 funzioni standard della libreria del C che prevedono l'output bufferizzato; e
517 questa bufferizzazione (trattata in dettaglio in sez.~\ref{sec:file_buffering})
518 varia a seconda che si tratti di un file su disco (in cui il buffer viene
519 scaricato su disco solo quando necessario) o di un terminale (nel qual caso il
520 buffer viene scaricato ad ogni carattere di a capo).
522 Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
523 buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
524 l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
525 non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
526 ogni figlio riceve una copia della memoria del padre, esso riceverà anche
527 quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
528 padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
529 figlio, troveremo nel file anche tutto quello che il processo padre aveva
530 scritto prima della sua creazione. E alla fine del file (dato che in questo
531 caso il padre esce per ultimo) troveremo anche l'output completo del padre.
533 L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
534 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
535 solo processi diversi possono scrivere in contemporanea sullo stesso file
536 (l'argomento della condivisione dei file è trattato in dettaglio in
537 sez.~\ref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
538 le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
541 Quello che succede è che quando lo standard output del padre viene rediretto,
542 lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha
543 la caratteristica di duplicare nei figli tutti i file descriptor aperti nel
544 padre (allo stesso modo in cui lo fa la funzione \func{dup}, trattata in
545 sez.~\ref{sec:file_dup}), il che comporta che padre e figli condividono le
546 stesse voci della \textit{file table} (per la spiegazione di questi termini si
547 veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente nel
550 In questo modo se un processo scrive sul file aggiornerà la posizione corrente
551 sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
552 \textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
553 casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
554 file, che l'output successivo di un processo vada a sovrapporsi a quello dei
555 precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
556 perdute per via di una sovrascrittura.
558 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
559 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
560 scrivono sullo stesso file (un caso tipico è la shell quando lancia un
561 programma, il cui output va sullo standard output).
563 In questo modo, anche se l'output viene rediretto, il padre potrà sempre
564 continuare a scrivere in coda a quanto scritto dal figlio in maniera
565 automatica; se così non fosse ottenere questo comportamento sarebbe
566 estremamente complesso necessitando di una qualche forma di comunicazione fra
567 i due processi per far riprendere al padre la scrittura al punto giusto.
569 In generale comunque non è buona norma far scrivere più processi sullo stesso
570 file senza una qualche forma di sincronizzazione in quanto, come visto anche
571 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
572 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
573 i file dopo una \func{fork} sono sostanzialmente due:
575 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
576 è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
577 della posizione corrente dopo eventuali operazioni di lettura e scrittura
578 effettuate dal figlio è automatica.
579 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
580 ciascuno dei due processi deve chiudere i file che non gli servono una volta
581 che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
584 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
585 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
586 comune dopo l'esecuzione di una \func{fork} è la seguente:
588 \item i file aperti e gli eventuali flag di
589 \textit{close-on-exec}\index{\textit{close-on-exec}} impostati (vedi
590 sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl});
591 \item gli identificatori per il controllo di accesso: l'\textsl{user-ID
592 reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
593 \textsl{group-ID effettivo} ed i \textit{group-ID supplementari} (vedi
594 sez.~\ref{sec:proc_access_id});
595 \item gli identificatori per il controllo di sessione: il \textit{process
596 group-ID} e il \textit{session id} ed il terminale di controllo (vedi
597 sez.~\ref{sec:sess_proc_group});
598 \item la directory di lavoro e la directory radice (vedi
599 sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
600 \item la maschera dei permessi di creazione (vedi sez.~\ref{sec:file_umask});
601 \item la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) e le
602 azioni installate (vedi sez.~\ref{sec:sig_gen_beha});
603 \item i segmenti di memoria condivisa agganciati al processo (vedi
604 sez.~\ref{sec:ipc_sysv_shm});
605 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
606 \item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
608 Le differenze fra padre e figlio dopo la \func{fork} invece sono:
610 \item il valore di ritorno di \func{fork};
611 \item il \acr{pid} (\textit{process id});
612 \item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
613 impostato al \acr{pid} del padre;
614 \item i valori dei tempi di esecuzione della struttura \struct{tms} (vedi
615 sez.~\ref{sec:sys_cpu_times}) che nel figlio sono posti a zero;
616 \item i \textit{lock} sui file (vedi sez.~\ref{sec:file_locking}), che non
617 vengono ereditati dal figlio;
618 \item gli allarmi ed i segnali pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che
619 per il figlio vengono cancellati.
623 \subsection{La funzione \func{vfork}}
624 \label{sec:proc_vfork}
626 La funzione \func{vfork} è esattamente identica a \func{fork} ed ha la stessa
627 semantica e gli stessi errori; la sola differenza è che non viene creata la
628 tabella delle pagine né la struttura dei task per il nuovo processo. Il
629 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
630 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
631 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
632 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
634 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
635 \func{fork} comportava anche la copia completa del segmento dati del processo
636 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
637 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
638 venne introdotta in BSD per migliorare le prestazioni.
640 Dato che Linux supporta il \textit{copy on
641 write}\index{\textit{copy~on~write}} la perdita di prestazioni è
642 assolutamente trascurabile, e l'uso di questa funzione (che resta un caso
643 speciale della system call \func{\_\_clone}) è deprecato; per questo eviteremo
644 di trattarla ulteriormente.
647 \subsection{La conclusione di un processo}
648 \label{sec:proc_termination}
650 In sez.~\ref{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 sez.~\ref{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 sez.~\ref{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 sez.~\ref{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 sez.~\ref{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
697 sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
698 caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
699 valore passato alle funzioni \func{exit} o \func{\_exit} (o dal valore di
700 ritorno per \func{main}). Ma se il processo viene concluso in maniera anomala
701 il programma non può specificare nessun \textit{exit status}, ed è il kernel
702 che deve generare autonomamente il \textit{termination status} per indicare le
703 ragioni della conclusione anomala.
705 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
706 quello che contraddistingue lo stato di chiusura del processo e viene
707 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
708 sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
709 il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
712 La scelta di riportare al padre lo stato di terminazione dei figli, pur
713 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
714 alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
715 che sia così alla sua conclusione, dato che il padre potrebbe essere già
716 terminato (si potrebbe avere cioè quello che si chiama un processo
719 Questa complicazione viene superata facendo in modo che il processo orfano
720 venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
721 termina, il kernel controlla se è il padre di altri processi in esecuzione: in
722 caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
723 con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
724 avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
725 cui riportare il suo stato di terminazione. Come verifica di questo
726 comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
727 ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
731 [piccardi@selidor sources]$ ./forktest -c2 3
732 Process 1972: forking 3 child
733 Spawned 1 child, pid 1973
734 Child 1 successfully executing
736 Spawned 2 child, pid 1974
737 Child 2 successfully executing
739 Child 3 successfully executing
740 Spawned 3 child, pid 1975
742 [piccardi@selidor sources]$ Child 3, parent 1, exiting
743 Child 2, parent 1, exiting
744 Child 1, parent 1, exiting
747 come si può notare in questo caso il processo padre si conclude prima dei
748 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
749 secondi dopo viene stampato a video anche l'output dei tre figli che
750 terminano, e come si può notare in questo caso, al contrario di quanto visto
751 in precedenza, essi riportano 1 come \acr{ppid}.
753 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
754 perché non è detto che il padre possa ricevere immediatamente lo stato di
755 terminazione, quindi il kernel deve comunque conservare una certa quantità di
756 informazioni riguardo ai processi che sta terminando.
758 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
759 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
760 dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
761 mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
762 processi che sono terminati, ma il cui stato di terminazione non è stato
763 ancora ricevuto dal padre sono chiamati \textit{zombie}\index{zombie}, essi
764 restano presenti nella tabella dei processi ed in genere possono essere
765 identificati dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella
766 colonna che ne indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando
767 il padre effettuerà la lettura dello stato di uscita anche questa
768 informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi
769 completamente conclusa.
771 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
772 condizione: lanciamo il comando \cmd{forktest} in background, indicando al
773 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
774 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
779 [piccardi@selidor sources]$ ps T
780 PID TTY STAT TIME COMMAND
781 419 pts/0 S 0:00 bash
782 568 pts/0 S 0:00 ./forktest -e10 3
783 569 pts/0 Z 0:00 [forktest <defunct>]
784 570 pts/0 Z 0:00 [forktest <defunct>]
785 571 pts/0 Z 0:00 [forktest <defunct>]
786 572 pts/0 R 0:00 ps T
788 \normalsize e come si vede, dato che non si è fatto nulla per riceverne lo
789 stato di terminazione, i tre processi figli sono ancora presenti pur essendosi
790 conclusi, con lo stato di zombie\index{zombie} e l'indicazione che sono stati
793 La possibilità di avere degli zombie\index{zombie} deve essere tenuta sempre
794 presente quando si scrive un programma che deve essere mantenuto in esecuzione
795 a lungo e creare molti figli. In questo caso si deve sempre avere cura di far
796 leggere l'eventuale stato di uscita di tutti i figli (in genere questo si fa
797 attraverso un apposito \textit{signal handler}, che chiama la funzione
798 \func{wait}, vedi sez.~\ref{sec:sig_sigchld} e sez.~\ref{sec:proc_wait}).
799 Questa operazione è necessaria perché anche se gli
800 \textit{zombie}\index{zombie} non consumano risorse di memoria o processore,
801 occupano comunque una voce nella tabella dei processi, che a lungo andare
804 Si noti che quando un processo adottato da \cmd{init} termina, esso non
805 diviene uno \textit{zombie}\index{zombie}; questo perché una delle funzioni di
806 \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i processi
807 cui fa da padre, completandone la terminazione. Questo è quanto avviene anche
808 quando, come nel caso del precedente esempio con \cmd{forktest}, il padre
809 termina con dei figli in stato di zombie\index{zombie}: alla sua terminazione
810 infatti tutti i suoi figli (compresi gli zombie\index{zombie}) verranno
811 adottati da \cmd{init}, il quale provvederà a completarne la terminazione.
813 Si tenga presente infine che siccome gli zombie\index{zombie} sono processi
814 già usciti, non c'è modo di eliminarli con il comando \cmd{kill}; l'unica
815 possibilità di cancellarli dalla tabella dei processi è quella di terminare il
816 processo che li ha generati, in modo che \cmd{init} possa adottarli e
817 provvedere a concluderne la terminazione.
820 \subsection{Le funzioni \func{wait} e \func{waitpid}}
821 \label{sec:proc_wait}
823 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
824 consiste nella creazione di programmi di tipo server, in cui un processo
825 principale attende le richieste che vengono poi soddisfatte da una serie di
826 processi figli. Si è già sottolineato al paragrafo precedente come in questo
827 caso diventi necessario gestire esplicitamente la conclusione dei figli onde
828 evitare di riempire di \textit{zombie}\index{zombie} la tabella dei processi;
829 le funzioni deputate a questo compito sono sostanzialmente due, \funcd{wait} e
830 \func{waitpid}. La prima, il cui prototipo è:
832 \headdecl{sys/types.h}
833 \headdecl{sys/wait.h}
834 \funcdecl{pid\_t wait(int *status)}
836 Sospende il processo corrente finché un figlio non è uscito, o finché un
837 segnale termina il processo o chiama una funzione di gestione.
839 \bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
840 e -1 in caso di errore; \var{errno} può assumere i valori:
842 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
846 è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
847 processo figlio termina. Se un figlio è già terminato la funzione ritorna
848 immediatamente, se più di un figlio è terminato occorre chiamare la funzione
849 più volte se si vuole recuperare lo stato di terminazione di tutti quanti.
851 Al ritorno della funzione lo stato di terminazione del figlio viene salvato
852 nella variabile puntata da \param{status} e tutte le risorse del kernel
853 relative al processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate.
854 Nel caso un processo abbia più figli il valore di ritorno (il \acr{pid} del
855 figlio) permette di identificare qual è quello che è uscito.
857 Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
858 all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
859 necessario attendere la conclusione di un processo specifico occorrerebbe
860 predisporre un meccanismo che tenga conto dei processi già terminati, e
861 provvedere a ripetere la chiamata alla funzione nel caso il processo cercato
864 Per questo motivo lo standard POSIX.1 ha introdotto la funzione
865 \funcd{waitpid} che effettua lo stesso servizio, ma dispone di una serie di
866 funzionalità più ampie, legate anche al controllo di sessione (si veda
867 sez.~\ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
868 comportamento di \func{wait} si consiglia di utilizzare sempre questa
869 funzione, il cui prototipo è:
871 \headdecl{sys/types.h}
872 \headdecl{sys/wait.h}
873 \funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
874 Attende la conclusione di un processo figlio.
876 \bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
877 è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e
878 -1 per un errore, nel qual caso \var{errno} assumerà i valori:
880 \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
881 la funzione è stata interrotta da un segnale.
882 \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
883 non è figlio del processo chiamante.
887 Le differenze principali fra le due funzioni sono che \func{wait} si blocca
888 sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la
889 possibilità si specificare un'opzione \const{WNOHANG} che ne previene il
890 blocco; inoltre \func{waitpid} può specificare in maniera flessibile quale
891 processo attendere, sulla base del valore fornito dall'argomento \param{pid},
892 secondo lo specchietto riportato in tab.~\ref{tab:proc_waidpid_pid}.
897 \begin{tabular}[c]{|c|c|p{8cm}|}
899 \textbf{Valore} & \textbf{Opzione} &\textbf{Significato}\\
902 $<-1$& -- & attende per un figlio il cui \textit{process group} (vedi
903 sez.~\ref{sec:sess_proc_group}) è uguale al
904 valore assoluto di \param{pid}. \\
905 $-1$ & \const{WAIT\_ANY} & attende per un figlio qualsiasi, usata in
906 questa maniera è equivalente a \func{wait}.\\
907 $0$ & \const{WAIT\_MYPGRP} & attende per un figlio il cui \textit{process
908 group} è uguale a quello del processo chiamante. \\
909 $>0$ & -- &attende per un figlio il cui \acr{pid} è uguale al
910 valore di \param{pid}.\\
913 \caption{Significato dei valori dell'argomento \param{pid} della funzione
915 \label{tab:proc_waidpid_pid}
918 Il comportamento di \func{waitpid} può inoltre essere modificato passando
919 delle opportune opzioni tramite l'argomento \param{option}. I valori possibili
920 sono il già citato \const{WNOHANG}, che previene il blocco della funzione
921 quando il processo figlio non è terminato, e \const{WUNTRACED} che permette di
922 tracciare i processi bloccati. Il valore dell'opzione deve essere specificato
923 come maschera binaria ottenuta con l'OR delle suddette costanti con zero.
925 In genere si utilizza \const{WUNTRACED} all'interno del controllo di sessione,
926 (l'argomento è trattato in sez.~\ref{sec:sess_job_control}). In tal caso
927 infatti la funzione ritorna, restituendone il \acr{pid}, quando c'è un
928 processo figlio che è entrato in stato di sleep (vedi
929 tab.~\ref{tab:proc_proc_states}) e del quale non si è ancora letto lo stato
930 (con questa stessa opzione). In Linux sono previste altre opzioni non standard
931 relative al comportamento con i thread, che riprenderemo in
932 sez.~\ref{sec:thread_xxx}.
934 La terminazione di un processo figlio è chiaramente un evento asincrono
935 rispetto all'esecuzione di un programma e può avvenire in un qualunque
936 momento. Per questo motivo, come accennato nella sezione precedente, una delle
937 azioni prese dal kernel alla conclusione di un processo è quella di mandare un
938 segnale di \const{SIGCHLD} al padre. L'azione predefinita (si veda
939 sez.~\ref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
940 generazione costituisce il meccanismo di comunicazione asincrona con cui il
941 kernel avverte il processo padre che uno dei suoi figli è terminato.
943 In genere in un programma non si vuole essere forzati ad attendere la
944 conclusione di un processo per proseguire, specie se tutto questo serve solo
945 per leggerne lo stato di chiusura (ed evitare la presenza di
946 \textit{zombie}\index{zombie}), per questo la modalità più usata per chiamare
947 queste funzioni è quella di utilizzarle all'interno di un \textit{signal
948 handler} (vedremo un esempio di come gestire \const{SIGCHLD} con i segnali
949 in sez.~\ref{sec:sig_example}). In questo caso infatti, dato che il segnale è
950 generato dalla terminazione di un figlio, avremo la certezza che la chiamata a
951 \func{wait} non si bloccherà.
956 \begin{tabular}[c]{|c|p{10cm}|}
958 \textbf{Macro} & \textbf{Descrizione}\\
961 \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
962 figlio che sia terminato normalmente. \\
963 \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
964 stato di uscita del processo (passato attraverso
965 \func{\_exit}, \func{exit} o come valore di
966 ritorno di \func{main}). Può essere valutata solo
967 se \val{WIFEXITED} ha restituito un valore non
969 \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
970 in maniera anomala a causa di un segnale che non
971 è stato catturato (vedi
972 sez.~\ref{sec:sig_notification}).\\
973 \macro{WTERMSIG(s)} & Restituisce il numero del segnale che ha causato
974 la terminazione anomala del processo. Può essere
975 valutata solo se \val{WIFSIGNALED} ha restituito
976 un valore non nullo.\\
977 \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
978 file di \textit{core dump}. Può essere valutata
979 solo se \val{WIFSIGNALED} ha restituito un valore
980 non nullo.\footnotemark \\
981 \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
982 \func{waitpid} è bloccato. L'uso è possibile solo
983 avendo specificato l'opzione \const{WUNTRACED}. \\
984 \macro{WSTOPSIG(s)} & Restituisce il numero del segnale che ha bloccato
985 il processo. Può essere valutata solo se
986 \val{WIFSTOPPED} ha restituito un valore non
990 \caption{Descrizione delle varie macro di preprocessore utilizzabili per
991 verificare lo stato di terminazione \var{s} di un processo.}
992 \label{tab:proc_status_macro}
995 \footnotetext{questa macro non è definita dallo standard POSIX.1, ma è
996 presente come estensione sia in Linux che in altri Unix.}
998 Entrambe le funzioni di attesa restituiscono lo stato di terminazione del
999 processo tramite il puntatore \param{status} (se non interessa memorizzare lo
1000 stato si può passare un puntatore nullo). Il valore restituito da entrambe le
1001 funzioni dipende dall'implementazione, e tradizionalmente alcuni bit (in
1002 genere 8) sono riservati per memorizzare lo stato di uscita, e altri per
1003 indicare il segnale che ha causato la terminazione (in caso di conclusione
1004 anomala), uno per indicare se è stato generato un core file, ecc.\footnote{le
1005 definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
1006 questo file non deve mai essere usato direttamente, esso viene incluso
1007 attraverso \file{<sys/wait.h>}.}
1009 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
1010 analizzare lo stato di uscita. Esse sono definite sempre in
1011 \file{<sys/wait.h>} ed elencate in tab.~\ref{tab:proc_status_macro} (si tenga
1012 presente che queste macro prendono come parametro la variabile di tipo
1013 \ctyp{int} puntata da \param{status}).
1015 Si tenga conto che nel caso di conclusione anomala il valore restituito da
1016 \val{WTERMSIG} può essere confrontato con le costanti definite in
1017 \file{signal.h} ed elencate in tab.~\ref{tab:sig_signal_list}, e stampato
1018 usando le apposite funzioni trattate in sez.~\ref{sec:sig_strsignal}.
1021 \subsection{Le funzioni \func{wait3} e \func{wait4}}
1022 \label{sec:proc_wait4}
1024 Linux, seguendo un'estensione di BSD, supporta altre due funzioni per la
1025 lettura dello stato di terminazione di un processo, analoghe alle precedenti
1026 ma che prevedono un ulteriore argomento attraverso il quale il kernel può
1027 restituire al padre informazioni sulle risorse usate dal processo terminato e
1028 dai vari figli. Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che
1029 diventano accessibili definendo la macro \macro{\_USE\_BSD}; i loro prototipi
1032 \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
1033 \headdecl{sys/resource.h}
1035 \funcdecl{pid\_t wait4(pid\_t pid, int *status, int options, struct rusage
1037 È identica a \func{waitpid} sia per comportamento che per i valori degli
1038 argomenti, ma restituisce in \param{rusage} un sommario delle risorse usate
1041 \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
1042 Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
1043 ormai deprecata in favore di \func{wait4}.
1046 la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene
1047 utilizzata anche dalla funzione \func{getrusage} (vedi
1048 sez.~\ref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
1049 processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
1052 \subsection{Le funzioni \func{exec}}
1053 \label{sec:proc_exec}
1055 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1056 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1057 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1058 processo chiama una di queste funzioni esso viene completamente sostituito dal
1059 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
1060 creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo
1061 heap, i dati ed il testo del processo corrente con un nuovo programma letto da
1064 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1065 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1066 (come mostrato in fig.~\ref{fig:proc_exec_relat}), sono tutte un front-end a
1067 \funcd{execve}. Il prototipo di quest'ultima è:
1068 \begin{prototype}{unistd.h}
1069 {int execve(const char *filename, char *const argv[], char *const envp[])}
1070 Esegue il programma contenuto nel file \param{filename}.
1072 \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
1073 qual caso \var{errno} può assumere i valori:
1075 \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è
1076 montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
1077 \item[\errcode{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente
1078 non è root, il processo viene tracciato, o il filesystem è montato con
1079 l'opzione \cmd{nosuid}.
1080 \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
1081 riconosciuto come tale, o compilato per un'altra architettura.
1082 \item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1083 necessari per eseguirlo non esistono.
1084 \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
1086 \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
1087 \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
1089 \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
1091 \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
1093 ed inoltre anche \errval{EFAULT}, \errval{ENOMEM}, \errval{EIO},
1094 \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, \errval{ENFILE},
1098 La funzione \func{exec} esegue il file o lo script indicato da
1099 \param{filename}, passandogli la lista di argomenti indicata da \param{argv}
1100 e come ambiente la lista di stringhe indicata da \param{envp}; entrambe le
1101 liste devono essere terminate da un puntatore nullo. I vettori degli
1102 argomenti e dell'ambiente possono essere acceduti dal nuovo programma
1103 quando la sua funzione \func{main} è dichiarata nella forma
1104 \code{main(int argc, char *argv[], char *envp[])}.
1106 Le altre funzioni della famiglia servono per fornire all'utente una serie di
1107 possibili diverse interfacce per la creazione di un nuovo processo. I loro
1111 \funcdecl{int execl(const char *path, const char *arg, ...)}
1112 \funcdecl{int execv(const char *path, char *const argv[])}
1113 \funcdecl{int execle(const char *path, const char *arg, ..., char
1115 \funcdecl{int execlp(const char *file, const char *arg, ...)}
1116 \funcdecl{int execvp(const char *file, char *const argv[])}
1118 Sostituiscono l'immagine corrente del processo con quella indicata nel primo
1119 argomento. Gli argomenti successivi consentono di specificare gli argomenti a
1120 linea di comando e l'ambiente ricevuti dal nuovo processo.
1122 \bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
1123 nel qual caso \var{errno} assumerà i valori visti in precedenza per
1127 Per capire meglio le differenze fra le funzioni della famiglia si può fare
1128 riferimento allo specchietto riportato in tab.~\ref{tab:proc_exec_scheme}. La
1129 prima differenza riguarda le modalità di passaggio dei valori che poi andranno
1130 a costituire gli argomenti a linea di comando (cioè i valori di
1131 \param{argv} e \param{argc} visti dalla funzione \func{main} del programma
1134 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
1135 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
1136 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
1137 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
1138 questo vettore \emph{deve} essere terminato da un puntatore nullo.
1140 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
1141 lista di puntatori, nella forma:
1142 \includecodesnip{listati/char_list.c}
1143 che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
1144 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1145 per indicare il nome del file che contiene il programma che verrà eseguito.
1150 \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1152 \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
1153 \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1155 &\func{execl}\texttt{ }&\func{execlp}&\func{execle}
1156 &\func{execv}\texttt{ }& \func{execvp}& \func{execve} \\
1159 argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
1160 argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
1162 filename completo &$\bullet$&&$\bullet$&$\bullet$&&$\bullet$\\
1163 ricerca su \var{PATH} &&$\bullet$&&&$\bullet$& \\
1165 ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
1166 uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1169 \caption{Confronto delle caratteristiche delle varie funzioni della
1170 famiglia \func{exec}.}
1171 \label{tab:proc_exec_scheme}
1174 La seconda differenza fra le funzioni riguarda le modalità con cui si
1175 specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
1176 indicano le due funzioni che replicano il comportamento della shell nello
1177 specificare il comando da eseguire; quando l'argomento \param{file} non
1178 contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
1179 e viene eseguita automaticamente una ricerca fra i file presenti nella lista
1180 di directory specificate dalla variabile di ambiente \var{PATH}. Il file che
1181 viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1182 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1183 sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
1184 proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
1185 non viene trovato nessun altro file viene finalmente restituito
1188 Le altre quattro funzioni si limitano invece a cercare di eseguire il file
1189 indicato dall'argomento \param{path}, che viene interpretato come il
1190 \index{\textit{pathname}}\textit{pathname} del programma.
1194 \includegraphics[width=16cm]{img/exec_rel}
1195 \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1196 \label{fig:proc_exec_relat}
1199 La terza differenza è come viene passata la lista delle variabili di ambiente.
1200 Con lo mnemonico \texttt{e} vengono indicate quelle funzioni che necessitano
1201 di un vettore di parametri \var{envp[]} analogo a quello usato per gli
1202 argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
1203 usano il valore della variabile \var{environ} (vedi
1204 sez.~\ref{sec:proc_environ}) del processo di partenza per costruire
1207 Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
1208 \func{exec} assume anche una serie di altre proprietà del processo chiamante;
1209 la lista completa è la seguente:
1211 \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
1213 \item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
1214 \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
1215 \item il \textit{session id} (\acr{sid}) ed il \textit{process group-ID}
1216 (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group};
1217 \item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term});
1218 \item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
1219 \item la directory radice e la directory di lavoro corrente (vedi
1220 sez.~\ref{sec:file_work_dir});
1221 \item la maschera di creazione dei file (\var{umask}, vedi
1222 sez.~\ref{sec:file_umask}) ed i \textit{lock} sui file (vedi
1223 sez.~\ref{sec:file_locking});
1224 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
1225 sez.~\ref{sec:sig_sigmask});
1226 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
1227 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
1228 \var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times}).
1231 Inoltre i segnali che sono stati impostati per essere ignorati nel processo
1232 chiamante mantengono la stessa impostazione pure nel nuovo programma, tutti
1233 gli altri segnali vengono impostati alla loro azione predefinita. Un caso
1234 speciale è il segnale \const{SIGCHLD} che, quando impostato a
1235 \const{SIG\_IGN}, può anche non essere reimpostato a \const{SIG\_DFL} (si veda
1236 sez.~\ref{sec:sig_gen_beha}).
1238 La gestione dei file aperti dipende dal valore che ha il flag di
1239 \textit{close-on-exec}\index{\textit{close-on-exec}} (vedi anche
1240 sez.~\ref{sec:file_fcntl}) per ciascun file descriptor. I file per cui è
1241 impostato vengono chiusi, tutti gli altri file restano aperti. Questo
1242 significa che il comportamento predefinito è che i file restano aperti
1243 attraverso una \func{exec}, a meno di una chiamata esplicita a \func{fcntl}
1244 che imposti il suddetto flag.
1246 Per le directory, lo standard POSIX.1 richiede che esse vengano chiuse
1247 attraverso una \func{exec}, in genere questo è fatto dalla funzione
1248 \func{opendir} (vedi sez.~\ref{sec:file_dir_read}) che effettua da sola
1249 l'impostazione del flag di
1250 \textit{close-on-exec}\index{\textit{close-on-exec}} sulle directory che apre,
1251 in maniera trasparente all'utente.
1253 Abbiamo detto che l'\textsl{user-ID reale} ed il \textsl{group-ID reale}
1254 restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
1255 l'\textsl{user-ID effettivo} ed il \textsl{group-ID effettivo} (il significato
1256 di questi identificatori è trattato in sez.~\ref{sec:proc_access_id}), tranne
1257 quando il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid}
1258 bit impostato, in questo caso l'\textsl{user-ID effettivo} ed il
1259 \textsl{group-ID effettivo} vengono impostati rispettivamente all'utente o al
1260 gruppo cui il file appartiene (per i dettagli vedi sez.~\ref{sec:proc_perms}).
1262 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1263 condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
1264 del programma per caricare le librerie necessarie ed effettuare il link
1265 dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
1266 dinamiche viene usato l'interprete indicato nel segmento \const{PT\_INTERP},
1267 in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
1268 \acr{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
1269 \acr{glibc}. Infine nel caso il file sia uno script esso deve iniziare con una
1270 linea nella forma \cmd{\#!/path/to/interpreter [argomenti]} dove l'interprete
1271 indicato deve essere un programma valido (binario, non un altro script) che
1272 verrà chiamato come se si fosse eseguito il comando \cmd{interpreter
1273 [argomenti] filename}.\footnote{si tenga presente che con Linux quanto viene
1274 scritto come \texttt{argomenti} viene passato all'inteprete come un unico
1275 argomento con una unica stringa di lunghezza massima di 127 caratteri e se
1276 questa dimensione viene ecceduta la stringa viene troncata; altri Unix hanno
1277 dimensioni massime diverse, e diversi comportamenti, ad esempio FreeBSD
1278 esegue la scansione della riga e la divide nei vari argomenti e se è troppo
1279 lunga restitituisce un errore di \const{ENAMETOOLONG}, una comparazione dei
1280 vari comportamenti si trova su
1281 \href{http://www.in-ulm.de/~mascheck/various/shebang/}
1282 {\texttt{http://www.in-ulm.de/\~mascheck/various/shebang/}}.}
1284 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1285 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
1286 processo, con \func{exec} si lancia un nuovo programma, con \func{exit} e
1287 \func{wait} si effettua e verifica la conclusione dei processi. Tutte le
1288 altre funzioni sono ausiliarie e servono per la lettura e l'impostazione dei
1289 vari parametri connessi ai processi.
1293 \section{Il controllo di accesso}
1294 \label{sec:proc_perms}
1296 In questa sezione esamineremo le problematiche relative al controllo di
1297 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
1298 usati, come questi possono essere modificati nella creazione e nel lancio di
1299 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1300 problematiche connesse ad una gestione accorta dei privilegi.
1303 \subsection{Gli identificatori del controllo di accesso}
1304 \label{sec:proc_access_id}
1306 Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in
1307 realtà già esistono estensioni di questo modello base, che lo rendono più
1308 flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
1309 o il \textit{Mandatory Access Control} di SELinux; inoltre basandosi sul
1310 lavoro effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo
1311 sviluppo di una infrastruttura di sicurezza, il \textit{Linux Security
1312 Modules}, o LSM, in grado di fornire diversi agganci a livello del kernel
1313 per modularizzare tutti i possibili controlli di accesso.} di sicurezza di
1314 un sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
1315 separazione fra l'amministratore (\textsl{root}, detto spesso anche
1316 \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
1317 utenti, per i quali invece vengono effettuati i vari controlli di accesso.
1319 %Benché il sistema sia piuttosto semplice (è basato su un solo livello di
1320 % separazione) il sistema permette una
1321 %notevole flessibilità,
1323 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1324 identificatori univoci, lo user-ID ed il group-ID; questi servono al kernel per
1325 identificare uno specifico utente o un gruppo di utenti, per poi poter
1326 controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
1327 esempio in sez.~\ref{sec:file_access_control} vedremo come ad ogni file vengano
1328 associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
1329 appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
1330 kernel nella gestione dei permessi di accesso.
1332 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1333 evidente che per poter implementare un controllo sulle operazioni occorre
1334 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1335 anche a ciascun processo dovrà essere associato ad un utente e ad un gruppo.
1337 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1338 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1339 disporre di privilegi diversi, o dover impersonare un altro utente per un
1340 limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
1341 prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
1342 rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
1343 \textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il
1344 \textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di
1345 filesystem}), secondo la situazione illustrata in
1346 tab.~\ref{tab:proc_uid_gid}.
1351 \begin{tabular}[c]{|c|c|l|p{7.3cm}|}
1353 \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
1354 & \textbf{Significato} \\
1357 \acr{uid} & \textit{real} & \textsl{user-ID reale}
1358 & indica l'utente che ha lanciato il programma\\
1359 \acr{gid} & '' &\textsl{group-ID reale}
1360 & indica il gruppo principale dell'utente che ha lanciato
1363 \acr{euid} & \textit{effective} &\textsl{user-ID effettivo}
1364 & indica l'utente usato nel controllo di accesso \\
1365 \acr{egid} & '' & \textsl{group-ID effettivo}
1366 & indica il gruppo usato nel controllo di accesso \\
1367 -- & -- & \textsl{group-ID supplementari}
1368 & indicano gli ulteriori gruppi cui l'utente appartiene \\
1370 -- & \textit{saved} & \textsl{user-ID salvato}
1371 & è una copia dell'\acr{euid} iniziale\\
1372 -- & '' & \textsl{group-ID salvato}
1373 & è una copia dell'\acr{egid} iniziale \\
1375 \acr{fsuid} & \textit{filesystem} &\textsl{user-ID di filesystem}
1376 & indica l'utente effettivo per l'accesso al filesystem \\
1377 \acr{fsgid} & '' & \textsl{group-ID di filesystem}
1378 & indica il gruppo effettivo per l'accesso al filesystem \\
1381 \caption{Identificatori di utente e gruppo associati a ciascun processo con
1382 indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
1383 \label{tab:proc_uid_gid}
1386 Al primo gruppo appartengono l'\textsl{user-ID reale} ed il \textsl{group-ID
1387 reale}: questi vengono impostati al login ai valori corrispondenti
1388 all'utente con cui si accede al sistema (e relativo gruppo principale).
1389 Servono per l'identificazione dell'utente e normalmente non vengono mai
1390 cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
1391 modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
1392 questa possibilità è usata proprio dal programma \cmd{login} che, una volta
1393 completata la procedura di autenticazione, lancia una shell per la quale
1394 imposta questi identificatori ai valori corrispondenti all'utente che entra
1397 Al secondo gruppo appartengono lo \textsl{user-ID effettivo} ed il
1398 \textsl{group-ID effettivo} (a cui si aggiungono gli eventuali \textsl{group-ID
1399 supplementari} dei gruppi dei quali l'utente fa parte). Questi sono invece
1400 gli identificatori usati nella verifiche dei permessi del processo e per il
1401 controllo di accesso ai file (argomento affrontato in dettaglio in
1402 sez.~\ref{sec:file_perm_overview}).
1404 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1405 \textit{real} tranne nel caso in cui, come accennato in
1406 sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
1407 \acr{suid} o \acr{sgid} impostati (il significato di questi bit è affrontato
1408 in dettaglio in sez.~\ref{sec:file_suid_sgid}). In questo caso essi saranno
1409 impostati all'utente e al gruppo proprietari del file. Questo consente, per
1410 programmi in cui ci sia necessità, di dare a qualunque utente normale
1411 privilegi o permessi di un altro (o dell'amministratore).
1413 Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi
1414 identificatori possono essere letti attraverso le rispettive funzioni:
1415 \funcd{getuid}, \funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, i loro
1419 \headdecl{sys/types.h}
1420 \funcdecl{uid\_t getuid(void)} Restituisce l'\textsl{user-ID reale} del
1423 \funcdecl{uid\_t geteuid(void)} Restituisce l'\textsl{user-ID effettivo} del
1426 \funcdecl{gid\_t getgid(void)} Restituisce il \textsl{group-ID reale} del
1429 \funcdecl{gid\_t getegid(void)} Restituisce il \textsl{group-ID effettivo}
1430 del processo corrente.
1432 \bodydesc{Queste funzioni non riportano condizioni di errore.}
1435 In generale l'uso di privilegi superiori deve essere limitato il più
1436 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1437 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1438 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1439 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1442 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
1443 \textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
1444 SVr4, e previsto dallo standard POSIX quando è definita la costante
1445 \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
1446 del programma su altri Unix è buona norma controllare sempre la
1447 disponibilità di queste funzioni controllando se questa costante è
1448 definita.} il secondo gruppo è specifico di Linux e viene usato per
1449 migliorare la sicurezza con NFS.
1451 L'\textsl{user-ID salvato} ed il \textsl{group-ID salvato} sono copie
1452 dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo} del processo
1453 padre, e vengono impostati dalla funzione \func{exec} all'avvio del processo,
1454 come copie dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo}
1455 dopo che questi sono stati impostati tenendo conto di eventuali \acr{suid} o
1456 \acr{sgid}. Essi quindi consentono di tenere traccia di quale fossero utente
1457 e gruppo effettivi all'inizio dell'esecuzione di un nuovo programma.
1459 L'\textsl{user-ID di filesystem} e il \textsl{group-ID di filesystem} sono
1460 un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
1461 (torneremo sull'argomento in sez.~\ref{sec:proc_setfsuid}). Essi sono una
1462 replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
1463 quali si sostituiscono per tutte le operazioni di verifica dei permessi
1464 relativi ai file (trattate in sez.~\ref{sec:file_perm_overview}). Ogni
1465 cambiamento effettuato sugli identificatori effettivi viene automaticamente
1466 riportato su di essi, per cui in condizioni normali si può tranquillamente
1467 ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
1470 \subsection{Le funzioni \func{setuid} e \func{setgid}}
1471 \label{sec:proc_setuid}
1473 Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
1474 di appartenenza) ad un processo sono rispettivamente \funcd{setuid} e
1475 \funcd{setgid}; come accennato in sez.~\ref{sec:proc_access_id} in Linux esse
1476 seguono la semantica POSIX che prevede l'esistenza dell'\textit{user-ID
1477 salvato} e del \textit{group-ID salvato}; i loro prototipi sono:
1480 \headdecl{sys/types.h}
1482 \funcdecl{int setuid(uid\_t uid)} Imposta l'\textsl{user-ID} del processo
1485 \funcdecl{int setgid(gid\_t gid)} Imposta il \textsl{group-ID} del processo
1488 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1489 di fallimento: l'unico errore possibile è \errval{EPERM}.}
1492 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1493 la prima; la seconda si comporta esattamente allo stesso modo facendo
1494 riferimento al \textsl{group-ID} invece che all'\textsl{user-ID}. Gli
1495 eventuali \textsl{group-ID supplementari} non vengono modificati.
1497 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1498 l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di
1499 sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e
1500 \textit{saved}) vengono impostati al valore specificato da \param{uid},
1501 altrimenti viene impostato solo l'\textsl{user-ID effettivo}, e soltanto se il
1502 valore specificato corrisponde o all'\textsl{user-ID reale} o
1503 all'\textsl{user-ID salvato}. Negli altri casi viene segnalato un errore (con
1506 Come accennato l'uso principale di queste funzioni è quello di poter
1507 consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati (vedi
1508 sez.~\ref{sec:file_suid_sgid}) di riportare l'\textsl{user-ID effettivo} a
1509 quello dell'utente che ha lanciato il programma, effettuare il lavoro che non
1510 necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
1512 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1513 viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene
1514 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1515 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1516 falsificare la registrazione. Per questo motivo questo file (e l'analogo
1517 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
1518 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
1519 esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
1520 crea terminali multipli su una console) appartengono a questo gruppo ed hanno
1521 il bit \acr{sgid} impostato.
1523 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1524 situazione degli identificatori è la seguente:
1527 \textsl{group-ID reale} &=& \textrm{\acr{gid} (del chiamante)} \\
1528 \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
1529 \textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
1531 in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
1532 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo. A
1533 questo punto il programma può eseguire una \code{setgid(getgid())} per
1534 impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
1535 \textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
1536 non sarà possibile lanciare dal terminale programmi che modificano detto file,
1537 in tal caso infatti la situazione degli identificatori sarebbe:
1540 \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
1541 \textsl{group-ID effettivo} &=& \textrm{\acr{gid}} \\
1542 \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
1544 e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
1545 \textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
1546 aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
1547 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
1548 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
1549 in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
1550 funzione avrà successo e riporterà la situazione a:
1553 \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
1554 \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
1555 \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
1557 consentendo l'accesso a \file{/var/log/utmp}.
1559 Occorre però tenere conto che tutto questo non è possibile con un processo con
1560 i privilegi di amministratore, in tal caso infatti l'esecuzione di una
1561 \func{setuid} comporta il cambiamento di tutti gli identificatori associati al
1562 processo, rendendo impossibile riguadagnare i privilegi di amministratore.
1563 Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
1564 crea una nuova shell per l'utente; ma quando si vuole cambiare soltanto
1565 l'\textsl{user-ID effettivo} del processo per cedere i privilegi occorre
1566 ricorrere ad altre funzioni (si veda ad esempio sez.~\ref{sec:proc_seteuid}).
1569 \subsection{Le funzioni \func{setreuid} e \func{setregid}}
1570 \label{sec:proc_setreuid}
1572 Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non
1573 supportando\footnote{almeno fino alla versione 4.3+BSD TODO, FIXME verificare
1574 e aggiornare la nota.} gli identificatori del gruppo \textit{saved}, le usa
1575 per poter scambiare fra di loro \textit{effective} e \textit{real}. I
1576 rispettivi prototipi sono:
1579 \headdecl{sys/types.h}
1581 \funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Imposta l'\textsl{user-ID
1582 reale} e l'\textsl{user-ID effettivo} del processo corrente ai valori
1583 specificati da \param{ruid} e \param{euid}.
1585 \funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Imposta il \textsl{group-ID
1586 reale} ed il \textsl{group-ID effettivo} del processo corrente ai valori
1587 specificati da \param{rgid} e \param{egid}.
1589 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1590 di fallimento: l'unico errore possibile è \errval{EPERM}.}
1593 La due funzioni sono analoghe ed il loro comportamento è identico; quanto
1594 detto per la prima riguardo l'user-ID, si applica immediatamente alla seconda
1595 per il group-ID. I processi non privilegiati possono impostare solo i valori
1596 del loro user-ID effettivo o reale; valori diversi comportano il fallimento
1597 della chiamata; l'amministratore invece può specificare un valore qualunque.
1598 Specificando un argomento di valore -1 l'identificatore corrispondente verrà
1599 lasciato inalterato.
1601 Con queste funzioni si possono scambiare fra loro gli user-ID reale e
1602 effettivo, e pertanto è possibile implementare un comportamento simile a
1603 quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
1604 scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
1607 In questo caso però occorre porre molta attenzione quando si creano nuovi
1608 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
1609 questo caso infatti essi avranno un user-ID reale privilegiato, che dovrà
1610 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
1611 programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
1612 prima della \func{exec} per uniformare l'user-ID reale a quello effettivo) in
1613 caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio
1614 e riottenere privilegi non previsti.
1616 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
1617 si pone per l'user-ID salvato: questa funzione deriva da un'implementazione che
1618 non ne prevede la presenza, e quindi non è possibile usarla per correggere la
1619 situazione come nel caso precedente. Per questo motivo in Linux tutte le volte
1620 che si imposta un qualunque valore diverso da quello dall'user-ID reale
1621 corrente, l'user-ID salvato viene automaticamente uniformato al valore
1622 dell'user-ID effettivo.
1625 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
1626 \label{sec:proc_seteuid}
1628 Le due funzioni \funcd{seteuid} e \funcd{setegid} sono un'estensione allo
1629 standard POSIX.1 (ma sono comunque supportate dalla maggior parte degli Unix)
1630 e vengono usate per cambiare gli identificatori del gruppo \textit{effective};
1631 i loro prototipi sono:
1634 \headdecl{sys/types.h}
1636 \funcdecl{int seteuid(uid\_t uid)} Imposta l'user-ID effettivo del processo
1637 corrente a \param{uid}.
1639 \funcdecl{int setegid(gid\_t gid)} Imposta il group-ID effettivo del processo
1640 corrente a \param{gid}.
1642 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1643 di fallimento: l'unico errore è \errval{EPERM}.}
1646 Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo
1647 la prima. Gli utenti normali possono impostare l'user-ID effettivo solo al
1648 valore dell'user-ID reale o dell'user-ID salvato, l'amministratore può
1649 specificare qualunque valore. Queste funzioni sono usate per permettere
1650 all'amministratore di impostare solo l'user-ID effettivo, dato che l'uso
1651 normale di \func{setuid} comporta l'impostazione di tutti gli identificatori.
1654 \subsection{Le funzioni \func{setresuid} e \func{setresgid}}
1655 \label{sec:proc_setresuid}
1657 Le due funzioni \funcd{setresuid} e \funcd{setresgid} sono un'estensione
1658 introdotta in Linux,\footnote{a partire dal kernel 2.1.44.} e permettono un
1659 completo controllo su tutti e tre i gruppi di identificatori (\textit{real},
1660 \textit{effective} e \textit{saved}), i loro prototipi sono:
1663 \headdecl{sys/types.h}
1665 \funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Imposta
1666 l'user-ID reale, l'user-ID effettivo e l'user-ID salvato del processo corrente
1667 ai valori specificati rispettivamente da \param{ruid}, \param{euid} e
1670 \funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Imposta il
1671 group-ID reale, il group-ID effettivo ed il group-ID salvato del processo
1672 corrente ai valori specificati rispettivamente da \param{rgid}, \param{egid} e
1675 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1676 di fallimento: l'unico errore è \errval{EPERM}.}
1679 Le due funzioni sono identiche, quanto detto per la prima riguardo gli user-ID
1680 si applica alla seconda per i group-ID. I processi non privilegiati possono
1681 cambiare uno qualunque degli user-ID solo ad un valore corrispondente o
1682 all'user-ID reale, o a quello effettivo o a quello salvato, l'amministratore
1683 può specificare i valori che vuole; un valore di -1 per un qualunque argomento
1684 lascia inalterato l'identificatore corrispondente.
1686 Per queste funzioni esistono anche due controparti che permettono di leggere
1687 in blocco i vari identificatori: \funcd{getresuid} e \funcd{getresgid}; i loro
1691 \headdecl{sys/types.h}
1693 \funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge
1694 l'user-ID reale, l'user-ID effettivo e l'user-ID salvato del processo corrente.
1696 \funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
1697 group-ID reale, il group-ID effettivo e il group-ID salvato del processo
1700 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
1701 fallimento: l'unico errore possibile è \errval{EFAULT} se gli indirizzi delle
1702 variabili di ritorno non sono validi.}
1705 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
1706 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
1707 specificati come puntatori (è un altro esempio di
1708 \index{\textit{value~result~argument}}\textit{value result argument}). Si noti
1709 che queste funzioni sono le uniche in grado di leggere gli identificatori del
1710 gruppo \textit{saved}.
1713 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
1714 \label{sec:proc_setfsuid}
1716 Queste funzioni servono per impostare gli identificatori del gruppo
1717 \textit{filesystem} che sono usati da Linux per il controllo dell'accesso ai
1718 file. Come già accennato in sez.~\ref{sec:proc_access_id} Linux definisce
1719 questo ulteriore gruppo di identificatori, che in circostanze normali sono
1720 assolutamente equivalenti a quelli del gruppo \textit{effective}, dato che
1721 ogni cambiamento di questi ultimi viene immediatamente riportato su di essi.
1723 C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
1724 identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
1725 ovviare ad un problema di sicurezza che si presenta quando si deve
1726 implementare un server NFS.
1728 Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
1729 file per assumere l'identità del singolo utente remoto, ma se questo viene
1730 fatto cambiando l'user-ID effettivo o l'user-ID reale il server si espone alla
1731 ricezione di eventuali segnali ostili da parte dell'utente di cui ha
1732 temporaneamente assunto l'identità. Cambiando solo l'user-ID di filesystem si
1733 ottengono i privilegi necessari per accedere ai file, mantenendo quelli
1734 originari per quanto riguarda tutti gli altri controlli di accesso, così che
1735 l'utente non possa inviare segnali al server NFS.
1737 Le due funzioni usate per cambiare questi identificatori sono \funcd{setfsuid}
1738 e \funcd{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
1739 usate se si intendono scrivere programmi portabili; i loro prototipi sono:
1741 \headdecl{sys/fsuid.h}
1743 \funcdecl{int setfsuid(uid\_t fsuid)} Imposta l'user-ID di filesystem del
1744 processo corrente a \param{fsuid}.
1746 \funcdecl{int setfsgid(gid\_t fsgid)} Imposta il group-ID di filesystem del
1747 processo corrente a \param{fsgid}.
1749 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1750 di fallimento: l'unico errore possibile è \errval{EPERM}.}
1752 \noindent queste funzioni hanno successo solo se il processo chiamante ha i
1753 privilegi di amministratore o, per gli altri utenti, se il valore specificato
1754 coincide con uno dei di quelli del gruppo \textit{real}, \textit{effective} o
1758 \subsection{Le funzioni \func{setgroups} e \func{getgroups}}
1759 \label{sec:proc_setgroups}
1761 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
1762 gruppi supplementari cui un utente può appartenere. Ogni processo può avere
1763 almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
1764 gruppi secondari può essere ottenuto con \func{sysconf} (vedi
1765 sez.~\ref{sec:sys_sysconf}), leggendo il parametro
1766 \texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
1767 ereditati dal processo padre e possono essere cambiati con queste funzioni.
1769 La funzione che permette di leggere i gruppi supplementari associati ad un
1770 processo è \funcd{getgroups}; questa funzione è definita nello standard
1771 POSIX.1, ed il suo prototipo è:
1773 \headdecl{sys/types.h}
1776 \funcdecl{int getgroups(int size, gid\_t list[])}
1778 Legge gli identificatori dei gruppi supplementari.
1780 \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
1781 successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
1784 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
1785 \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
1786 minore del numero di gruppi supplementari del processo.
1790 La funzione legge gli identificatori dei gruppi supplementari del processo sul
1791 vettore \param{list} di dimensione \param{size}. Non è specificato se la
1792 funzione inserisca o meno nella lista il group-ID effettivo del processo. Se si
1793 specifica un valore di \param{size} uguale a 0 \param{list} non viene
1794 modificato, ma si ottiene il numero di gruppi supplementari.
1796 Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
1797 ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è:
1799 \headdecl{sys/types.h}
1802 \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups,
1803 int *ngroups)} Legge i gruppi supplementari.
1805 \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori,
1806 restituisce 0 in caso di successo e -1 in caso di fallimento.}
1809 La funzione legge i gruppi supplementari dell'utente specificato da
1810 \param{user}, eseguendo una scansione del database dei gruppi (si veda
1811 sez.~\ref{sec:sys_user_group}). Ritorna poi in \param{groups} la lista di
1812 quelli a cui l'utente appartiene. Si noti che \param{ngroups} è passato come
1813 puntatore perché, qualora il valore specificato sia troppo piccolo, la
1814 funzione ritorna -1, passando indietro il numero dei gruppi trovati.
1816 Per impostare i gruppi supplementari di un processo ci sono due funzioni, che
1817 possono essere usate solo se si hanno i privilegi di amministratore. La prima
1818 delle due è \funcd{setgroups}, ed il suo prototipo è:
1820 \headdecl{sys/types.h}
1823 \funcdecl{int setgroups(size\_t size, gid\_t *list)}
1825 Imposta i gruppi supplementari del processo.
1827 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1828 fallimento, nel qual caso \var{errno} assumerà i valori:
1830 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
1831 \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
1832 \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
1837 La funzione imposta i gruppi supplementari del processo corrente ai valori
1838 specificati nel vettore passato con l'argomento \param{list}, di dimensioni
1839 date dall'argomento \param{size}. Il numero massimo di gruppi supplementari è
1840 un parametro di sistema, che può essere ricavato con le modalità spiegate in
1841 sez.~\ref{sec:sys_characteristics}.
1843 Se invece si vogliono impostare i gruppi supplementari del processo a quelli di
1844 un utente specifico, si può usare \funcd{initgroups} il cui prototipo è:
1846 \headdecl{sys/types.h}
1849 \funcdecl{int initgroups(const char *user, gid\_t group)}
1851 Inizializza la lista dei gruppi supplementari.
1853 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1854 fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
1855 \func{setgroups} più \errval{ENOMEM} quando non c'è memoria sufficiente
1856 per allocare lo spazio per informazioni dei gruppi.}
1859 La funzione esegue la scansione del database dei gruppi (usualmente
1860 \file{/etc/groups}) cercando i gruppi di cui è membro l'utente \param{user}
1861 con cui costruisce una lista di gruppi supplementari, a cui aggiunge anche
1862 \param{group}, infine imposta questa lista per il processo corrente usando
1863 \func{setgroups}. Si tenga presente che sia \func{setgroups} che
1864 \func{initgroups} non sono definite nello standard POSIX.1 e che pertanto non
1865 è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si
1866 compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole
1867 scrivere codice portabile.
1872 % insieme alla risistemazioni dei titoli delle sezioni precedenti
1873 % (accorpare il materiale) qualosa tipo:
1874 % le funzioni di controllo
1875 % estenzioni di Linux
1877 %\subsection{La gestione delle capabilities}
1878 %\label{sec:proc_capabilities}
1883 \section{La gestione della priorità di esecuzione}
1884 \label{sec:proc_priority}
1886 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
1887 lo \textit{scheduler}\index{\textit{scheduler}} assegna la CPU ai vari
1888 processi attivi. In particolare prenderemo in esame i vari meccanismi con cui
1889 viene gestita l'assegnazione del tempo di CPU, ed illustreremo le varie
1890 funzioni di gestione.
1893 \subsection{I meccanismi di \textit{scheduling}}
1894 \label{sec:proc_sched}
1896 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
1897 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
1898 ed oggetto di numerose ricerche; in generale essa dipende in maniera
1899 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
1900 cui non esiste un meccanismo che sia valido per tutti gli usi.
1902 La caratteristica specifica di un sistema multitasking come Linux è quella del
1903 cosiddetto \textit{prehemptive multitasking}: questo significa che al
1904 contrario di altri sistemi (che usano invece il cosiddetto \textit{cooperative
1905 multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
1906 quando la CPU deve essere passata ad un altro processo. Come accennato in
1907 sez.~\ref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
1908 apposita del kernel, lo \textit{scheduler}\index{\textit{scheduler}}, il cui
1909 scopo è quello di distribuire al meglio il tempo di CPU fra i vari processi.
1911 La cosa è resa ancora più complicata dal fatto che con le architetture
1912 multi-processore si deve anche scegliere quale sia la CPU più opportuna da
1913 utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
1914 rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
1915 un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
1916 banale.} Tutto questo comunque appartiene alle sottigliezze
1917 dell'implementazione del kernel; dal punto di vista dei programmi che girano
1918 in user space, anche quando si hanno più processori (e dei processi che sono
1919 eseguiti davvero in contemporanea), le politiche di scheduling riguardano
1920 semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui
1921 assegnazione sarà governata dai meccanismi di scelta delle priorità che
1922 restano gli stessi indipendentemente dal numero di processori.
1924 Si tenga conto poi che i processi non devono solo eseguire del codice: ad
1925 esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
1926 venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
1927 tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
1928 kernel provvedere a mettere in esecuzione un altro processo.
1930 Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
1931 processo, in Linux un processo può trovarsi in uno degli stati riportati in
1932 tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
1933 \textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
1934 sia la sua priorità, un processo non potrà mai essere messo in esecuzione
1935 fintanto che esso si trova in uno qualunque degli altri stati.
1940 \begin{tabular}[c]{|p{2.8cm}|c|p{10cm}|}
1942 \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
1945 \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
1946 essere eseguito (cioè è in attesa che gli
1947 venga assegnata la CPU). \\
1948 \textbf{Sleep} & \texttt{S} & Il processo è in attesa di un
1949 risposta dal sistema, ma può essere
1950 interrotto da un segnale. \\
1951 \textbf{Uninterrutible Sleep}& \texttt{D} & Il processo è in
1952 attesa di un risposta dal sistema (in
1953 genere per I/O), e non può essere
1954 interrotto in nessuna circostanza. \\
1955 \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
1956 \const{SIGSTOP}, o è tracciato.\\
1957 \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
1958 suo stato di terminazione non è ancora
1959 stato letto dal padre. \\
1962 \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
1963 \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
1964 \cmd{ps} nell'omonimo campo.}
1965 \label{tab:proc_proc_states}
1968 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
1969 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
1970 dello scopo del programma non è detto neanche che sia la più importante (molti
1971 programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
1972 non è affatto detto che dare ad un programma la massima priorità di esecuzione
1973 abbia risultati significativi in termini di prestazioni.
1975 Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
1976 sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
1977 \textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
1978 i meno importanti, possano ricevere un po' di tempo di CPU. In sostanza quando
1979 un processo ottiene la CPU la sua priorità viene diminuita. In questo modo
1980 alla fine, anche un processo con priorità iniziale molto bassa, finisce per
1981 avere una priorità sufficiente per essere eseguito.
1983 Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
1984 assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
1985 alla normale priorità dinamica), per tenere conto dei sistemi
1986 real-time,\footnote{per sistema real-time si intende un sistema in grado di
1987 eseguire operazioni in un tempo ben determinato; in genere si tende a
1988 distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
1989 esecuzione di un programma siano determinabili con certezza assoluta (come
1990 nel caso di meccanismi di controllo di macchine, dove uno sforamento dei
1991 tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un
1992 occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
1993 processi che devono essere eseguiti in un determinato momento non debbano
1994 aspettare la conclusione di altri che non hanno questa necessità.
1996 Il concetto di priorità assoluta dice che quando due processi si contendono
1997 l'esecuzione, vince sempre quello con la priorità assoluta più alta.
1998 Ovviamente questo avviene solo per i processi che sono pronti per essere
1999 eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
2000 genere indicata con un numero intero, ed un valore più alto comporta una
2001 priorità maggiore. Su questa politica di scheduling torneremo in
2002 sez.~\ref{sec:proc_real_time}.
2004 In generale quello che succede in tutti gli Unix moderni è che ai processi
2005 normali viene sempre data una priorità assoluta pari a zero, e la decisione di
2006 assegnazione della CPU è fatta solo con il meccanismo tradizionale della
2007 priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
2008 assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
2009 priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
2013 \subsection{Il meccanismo di \textit{scheduling} standard}
2014 \label{sec:proc_sched_stand}
2016 A meno che non si abbiano esigenze specifiche, l'unico meccanismo di
2017 scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
2018 solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
2019 nella programmazione.
2021 Come accennato in Linux tutti i processi ordinari hanno la stessa priorità
2022 assoluta. Quello che determina quale, fra tutti i processi in attesa di
2023 esecuzione, sarà eseguito per primo, è la priorità dinamica, che è chiamata
2024 così proprio perché varia nel corso dell'esecuzione di un processo. Oltre a
2025 questo la priorità dinamica determina quanto a lungo un processo continuerà ad
2026 essere eseguito, e quando un processo potrà subentrare ad un altro
2029 Il meccanismo usato da Linux è piuttosto semplice, ad ogni processo è
2030 assegnata una \textit{time-slice}, cioè un intervallo di tempo (letteralmente
2031 una fetta) per il quale esso deve essere eseguito. Il valore della
2032 \textit{time-slice} è controllato dalla cosiddetta \textit{nice} (o
2033 \textit{niceness}) del processo. Essa è contenuta nel campo \var{nice} di
2034 \struct{task\_struct}; tutti i processi vengono creati con lo stesso valore,
2035 ed essa specifica il valore della durata iniziale della \textit{time-slice}
2036 che viene assegnato ad un altro campo della struttura (\var{counter}) quando
2037 il processo viene eseguito per la prima volta e diminuito progressivamente ad
2038 ogni interruzione del timer.
2040 Durante la sua esecuzione lo scheduler\index{\textit{scheduler}} scandisce la
2041 coda dei processi in stato \textit{runnable} associando, in base al valore di
2042 \var{counter}, un peso ad ogni processo in attesa di esecuzione,\footnote{il
2043 calcolo del peso in realtà è un po' più complicato, ad esempio nei sistemi
2044 multiprocessore viene favorito un processo eseguito sulla stessa CPU, e a
2045 parità del valore di \var{counter} viene favorito chi ha una priorità più
2046 elevata.} chi ha il peso più alto verrà posto in esecuzione, ed il
2047 precedente processo sarà spostato in fondo alla coda. Dato che ad ogni
2048 interruzione del timer il valore di \var{counter} del processo corrente viene
2049 diminuito, questo assicura che anche i processi con priorità più bassa
2050 verranno messi in esecuzione.
2052 La priorità di un processo è così controllata attraverso il valore di
2053 \var{nice}, che stabilisce la durata della \textit{time-slice}; per il
2054 meccanismo appena descritto infatti un valore più lungo assicura una maggiore
2055 attribuzione di CPU. L'origine del nome di questo parametro sta nel fatto che
2056 generalmente questo viene usato per diminuire la priorità di un processo, come
2057 misura di cortesia nei confronti degli altri. I processi infatti vengono
2058 creati dal sistema con lo stesso valore di \var{nice} (nullo) e nessuno è
2059 privilegiato rispetto agli altri; il valore può essere modificato solo
2060 attraverso la funzione \funcd{nice}, il cui prototipo è:
2061 \begin{prototype}{unistd.h}
2063 Aumenta il valore di \var{nice} per il processo corrente.
2065 \bodydesc{La funzione ritorna zero in caso di successo e -1 in caso di
2066 errore, nel qual caso \var{errno} può assumere i valori:
2068 \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
2069 specificato un valore di \param{inc} negativo.
2073 L'argomento \param{inc} indica l'incremento del valore di \var{nice}:
2074 quest'ultimo può assumere valori compresi fra \const{PRIO\_MIN} e
2075 \const{PRIO\_MAX} (che nel caso di Linux sono $-19$ e $20$), ma per
2076 \param{inc} si può specificare un valore qualunque, positivo o negativo, ed il
2077 sistema provvederà a troncare il risultato nell'intervallo consentito. Valori
2078 positivi comportano maggiore \textit{cortesia} e cioè una diminuzione della
2079 priorità, ogni utente può solo innalzare il valore di un suo processo. Solo
2080 l'amministratore può specificare valori negativi che permettono di aumentare
2081 la priorità di un processo.
2083 In SUSv2 la funzione ritorna il nuovo valore di \var{nice}; Linux non segue
2084 questa convenzione, e per leggere il nuovo valore occorre invece usare la
2085 funzione \funcd{getpriority}, derivata da BSD, il cui prototipo è:
2086 \begin{prototype}{sys/resource.h}
2087 {int getpriority(int which, int who)}
2089 Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
2091 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2092 errore, nel qual caso \var{errno} può assumere i valori:
2094 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2095 \param{which} e \param{who}.
2096 \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
2099 \noindent nelle vecchie versioni può essere necessario includere anche
2100 \file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
2101 librerie, ma è comunque utile per portabilità.
2103 La funzione permette, a seconda del valore di \param{which}, di leggere la
2104 priorità di un processo, di un gruppo di processi (vedi
2105 sez.~\ref{sec:sess_proc_group}) o di un utente, specificando un corrispondente
2106 valore per \param{who} secondo la legenda di tab.~\ref{tab:proc_getpriority};
2107 un valore nullo di quest'ultimo indica il processo, il gruppo di processi o
2113 \begin{tabular}[c]{|c|c|l|}
2115 \param{which} & \param{who} & \textbf{Significato} \\
2118 \const{PRIO\_PROCESS} & \type{pid\_t} & processo \\
2119 \const{PRIO\_PRGR} & \type{pid\_t} & process group \\
2120 \const{PRIO\_USER} & \type{uid\_t} & utente \\
2123 \caption{Legenda del valore dell'argomento \param{which} e del tipo
2124 dell'argomento \param{who} delle funzioni \func{getpriority} e
2125 \func{setpriority} per le tre possibili scelte.}
2126 \label{tab:proc_getpriority}
2129 La funzione restituisce la priorità più alta (cioè il valore più basso) fra
2130 quelle dei processi specificati; dato che -1 è un valore possibile, per poter
2131 rilevare una condizione di errore è necessario cancellare sempre \var{errno}
2132 prima della chiamata alla funzione, per verificare che essa resti uguale a
2135 Analoga a \func{getpriority} la funzione \funcd{setpriority} permette di
2136 impostare la priorità di uno o più processi; il suo prototipo è:
2137 \begin{prototype}{sys/resource.h}
2138 {int setpriority(int which, int who, int prio)}
2139 Imposta la priorità per l'insieme dei processi specificati.
2141 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2142 errore, nel qual caso \var{errno} può assumere i valori:
2144 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2145 \param{which} e \param{who}.
2146 \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
2147 \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
2148 specificato un valore di \param{inc} negativo.
2149 \item[\errcode{EACCES}] un processo senza i privilegi di amministratore ha
2150 cercato di modificare la priorità di un processo di un altro utente.
2154 La funzione imposta la priorità al valore specificato da \param{prio} per
2155 tutti i processi indicati dagli argomenti \param{which} e \param{who}. La
2156 gestione dei permessi dipende dalle varie implementazioni; in Linux, secondo
2157 le specifiche dello standard SUSv3, e come avviene per tutti i sistemi che
2158 derivano da SysV, è richiesto che l'user-ID reale o effettivo del processo
2159 chiamante corrispondano al real user-ID (e solo quello) del processo di cui si
2160 vuole cambiare la priorità; per i sistemi derivati da BSD invece (SunOS,
2161 Ultrix, *BSD) la corrispondenza può essere anche con l'user-ID effettivo.
2165 \subsection{Il meccanismo di \textit{scheduling real-time}}
2166 \label{sec:proc_real_time}
2168 Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto
2169 le priorità assolute per permettere la gestione di processi real-time. In
2170 realtà nel caso di Linux non si tratta di un vero hard real-time, in quanto in
2171 presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
2172 processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
2173 siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
2174 ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
2175 interrupt vengono intercettati dall'interfaccia real-time (o nel caso di
2176 Adeos gestiti dalle code del nano-kernel), in modo da poterli controllare
2177 direttamente qualora ci sia la necessità di avere un processo con priorità
2178 più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
2179 page fault\index{\textit{page~fault}} si possono avere ritardi non previsti.
2180 Se l'ultimo problema può essere aggirato attraverso l'uso delle funzioni di
2181 controllo della memoria virtuale (vedi sez.~\ref{sec:proc_mem_lock}), il primo
2182 non è superabile e può comportare ritardi non prevedibili riguardo ai tempi di
2183 esecuzione di qualunque processo.
2185 Occorre usare le priorità assolute con molta attenzione: se si dà ad un
2186 processo una priorità assoluta e questo finisce in un loop infinito, nessun
2187 altro processo potrà essere eseguito, ed esso sarà mantenuto in esecuzione
2188 permanentemente assorbendo tutta la CPU e senza nessuna possibilità di
2189 riottenere l'accesso al sistema. Per questo motivo è sempre opportuno, quando
2190 si lavora con processi che usano priorità assolute, tenere attiva una shell
2191 cui si sia assegnata la massima priorità assoluta, in modo da poter essere
2192 comunque in grado di rientrare nel sistema.
2194 Quando c'è un processo con priorità assoluta lo
2195 scheduler\index{\textit{scheduler}} lo metterà in esecuzione prima di ogni
2196 processo normale. In caso di più processi sarà eseguito per primo quello con
2197 priorità assoluta più alta. Quando ci sono più processi con la stessa priorità
2198 assoluta questi vengono tenuti in una coda e tocca al kernel decidere quale
2199 deve essere eseguito. Il meccanismo con cui vengono gestiti questi processi
2200 dipende dalla politica di scheduling che si è scelto; lo standard ne prevede
2202 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
2203 \item[\textit{FIFO}] \textit{First In First Out}. Il processo viene eseguito
2204 fintanto che non cede volontariamente la CPU, si blocca, finisce o viene
2205 interrotto da un processo a priorità più alta.
2206 \item[\textit{RR}] \textit{Round Robin}. Ciascun processo viene eseguito a
2207 turno per un certo periodo di tempo (una \textit{time slice}). Solo i
2208 processi con la stessa priorità ed in stato \textit{runnable} entrano nel
2212 La funzione per impostare le politiche di scheduling (sia real-time che
2213 ordinarie) ed i relativi parametri è \funcd{sched\_setscheduler}; il suo
2215 \begin{prototype}{sched.h}
2216 {int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
2217 Imposta priorità e politica di scheduling.
2219 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso
2220 di errore, nel qual caso \var{errno} può assumere i valori:
2222 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2223 \item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
2224 relativo valore di \param{p} non è valido.
2225 \item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
2230 La funzione esegue l'impostazione per il processo specificato dall'argomento
2231 \param{pid}; un valore nullo esegue l'impostazione per il processo corrente.
2232 La politica di scheduling è specificata dall'argomento \param{policy} i cui
2233 possibili valori sono riportati in tab.~\ref{tab:proc_sched_policy}; un valore
2234 negativo per \param{policy} mantiene la politica di scheduling corrente.
2235 Solo un processo con i privilegi di amministratore può impostare priorità
2236 assolute diverse da zero o politiche \const{SCHED\_FIFO} e \const{SCHED\_RR}.
2241 \begin{tabular}[c]{|c|l|}
2243 \textbf{Policy} & \textbf{Significato} \\
2246 \const{SCHED\_FIFO} & Scheduling real-time con politica \textit{FIFO} \\
2247 \const{SCHED\_RR} & Scheduling real-time con politica \textit{Round
2249 \const{SCHED\_OTHER}& Scheduling ordinario\\
2252 \caption{Valori dell'argomento \param{policy} per la funzione
2253 \func{sched\_setscheduler}. }
2254 \label{tab:proc_sched_policy}
2257 Il valore della priorità è passato attraverso la struttura
2258 \struct{sched\_param} (riportata in fig.~\ref{fig:sig_sched_param}), il cui
2259 solo campo attualmente definito è \var{sched\_priority}, che nel caso delle
2260 priorità assolute deve essere specificato nell'intervallo fra un valore
2261 massimo ed uno minimo, che nel caso sono rispettivamente 1 e 99 (il valore
2262 zero è legale, ma indica i processi normali).
2264 \begin{figure}[!bht]
2265 \footnotesize \centering
2266 \begin{minipage}[c]{15cm}
2267 \includestruct{listati/sched_param.c}
2270 \caption{La struttura \structd{sched\_param}.}
2271 \label{fig:sig_sched_param}
2274 Lo standard POSIX.1b prevede comunque che i due valori della massima e minima
2275 priorità statica possano essere ottenuti, per ciascuna delle politiche di
2276 scheduling \textit{real-time}, tramite le due funzioni
2277 \funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
2282 \funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
2283 massimo della priorità statica per la politica di scheduling \param{policy}.
2286 \funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
2287 della priorità statica per la politica di scheduling \param{policy}.
2289 \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
2290 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2292 \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
2297 I processi con politica di scheduling \const{SCHED\_OTHER} devono specificare
2298 un valore nullo (altrimenti si avrà un errore \errcode{EINVAL}), questo valore
2299 infatti non ha niente a che vedere con la priorità dinamica determinata dal
2300 valore di \var{nice}, che deve essere impostato con le funzioni viste in
2303 Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
2304 esegue sempre il primo della lista, mentre un nuovo processo che torna in
2305 stato \textit{runnable} viene sempre inserito in coda alla lista. Se la
2306 politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
2307 automaticamente rimesso in coda alla lista, e la sua esecuzione continua
2308 fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
2309 volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
2310 sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
2311 nel caso che esso sia stato interrotto da un processo a priorità più alta.
2313 La priorità assoluta può essere riletta indietro dalla funzione
2314 \funcd{sched\_getscheduler}, il cui prototipo è:
2315 \begin{prototype}{sched.h}
2316 {int sched\_getscheduler(pid\_t pid)}
2317 Legge la politica di scheduling per il processo \param{pid}.
2319 \bodydesc{La funzione ritorna la politica di scheduling in caso di successo
2320 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2322 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2323 \item[\errcode{EINVAL}] il valore di \param{pid} è negativo.
2327 La funzione restituisce il valore (secondo quanto elencato in
2328 tab.~\ref{tab:proc_sched_policy}) della politica di scheduling per il processo
2329 specificato; se \param{pid} è nullo viene restituito quello del processo
2332 Se si intende operare solo sulla priorità assoluta di un processo si possono
2333 usare le funzioni \funcd{sched\_setparam} e \funcd{sched\_getparam}, i cui
2338 \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *p)}
2339 Imposta la priorità assoluta del processo \param{pid}.
2341 \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *p)}
2342 Legge la priorità assoluta del processo \param{pid}.
2344 \bodydesc{La funzione ritorna la priorità in caso di successo
2345 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2347 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2348 \item[\errcode{EINVAL}] il valore di \param{pid} è negativo.
2352 L'uso di \func{sched\_setparam} che è del tutto equivalente a
2353 \func{sched\_setscheduler} con \param{priority} uguale a -1. Come per
2354 \func{sched\_setscheduler} specificando 0 come valore di \param{pid} si opera
2355 sul processo corrente. La disponibilità di entrambe le funzioni può essere
2356 verificata controllando la macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è
2357 definita nell'header \file{sched.h}.
2359 L'ultima funzione che permette di leggere le informazioni relative ai processi
2360 real-time è \funcd{sched\_rr\_get\_interval}, che permette di ottenere la
2361 lunghezza della \textit{time slice} usata dalla politica \textit{round robin};
2363 \begin{prototype}{sched.h}
2364 {int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
2365 \param{tp} la durata della \textit{time slice} per il processo \param{pid}.
2367 \bodydesc{La funzione ritorna 0in caso di successo e -1 in caso di errore,
2368 nel qual caso \var{errno} può assumere i valori:
2370 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2371 \item[\errcode{ENOSYS}] la system call non è stata implementata.
2375 La funzione restituisce il valore dell'intervallo di tempo usato per la
2376 politica \textit{round robin} in una struttura \struct{timespec}, (la cui
2377 definizione si può trovare in fig.~\ref{fig:sys_timeval_struct}).
2380 Come accennato ogni processo che usa lo scheduling real-time può rilasciare
2381 volontariamente la CPU; questo viene fatto attraverso la funzione
2382 \funcd{sched\_yield}, il cui prototipo è:
2383 \begin{prototype}{sched.h}
2384 {int sched\_yield(void)}
2386 Rilascia volontariamente l'esecuzione.
2388 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
2389 nel qual caso \var{errno} viene impostata opportunamente.}
2392 La funzione fa sì che il processo rilasci la CPU, in modo da essere rimesso in
2393 coda alla lista dei processi da eseguire, e permettere l'esecuzione di un
2394 altro processo; se però il processo è l'unico ad essere presente sulla coda
2395 l'esecuzione non sarà interrotta. In genere usano questa funzione i processi
2396 in modalità \textit{fifo}, per permettere l'esecuzione degli altri processi
2397 con pari priorità quando la sezione più urgente è finita.
2400 \section{Problematiche di programmazione multitasking}
2401 \label{sec:proc_multi_prog}
2403 Benché i processi siano strutturati in modo da apparire il più possibile come
2404 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
2405 occorre tenere conto di una serie di problematiche che normalmente non
2406 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
2407 programma alla volta.
2409 Pur essendo questo argomento di carattere generale, ci è parso opportuno
2410 introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
2411 in capitoli successivi, in questa sezione conclusiva del capitolo in cui
2412 abbiamo affrontato la gestione dei processi.
2415 \subsection{Le operazioni atomiche}
2416 \label{sec:proc_atom_oper}
2418 La nozione di \textsl{operazione atomica} deriva dal significato greco della
2419 parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
2420 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
2421 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
2422 di interruzione in una fase intermedia.
2424 In un ambiente multitasking il concetto è essenziale, dato che un processo può
2425 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
2426 altro processo o dalla ricezione di un segnale; occorre pertanto essere
2427 accorti nei confronti delle possibili
2428 \textit{race condition}\index{\textit{race~condition}} (vedi
2429 sez.~\ref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase
2430 in cui non erano ancora state completate.
2432 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
2433 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
2434 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
2435 cap.~\ref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
2436 sez.~\ref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
2437 funzioni di libreria per compiere le operazioni necessarie è garanzia
2438 sufficiente di atomicità in quanto le system call con cui esse sono realizzate
2439 non possono essere interrotte (o subire interferenze pericolose) da altri
2442 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
2443 stesso processo, e pure alcune system call, possono essere interrotti in
2444 qualunque momento, e le operazioni di un eventuale \textit{signal handler}
2445 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
2446 il solo accesso o l'assegnazione di una variabile possono non essere più
2447 operazioni atomiche (torneremo su questi aspetti in
2448 sez.~\ref{sec:sig_control}).
2450 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
2451 il cui accesso è assicurato essere atomico. In pratica comunque si può
2452 assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
2453 \ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
2454 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
2455 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
2456 le strutture. In tutti questi casi è anche opportuno marcare come
2457 \direct{volatile} le variabili che possono essere interessate ad accesso
2458 condiviso, onde evitare problemi con le ottimizzazioni del codice.
2462 \subsection{Le \textit{race condition} ed i \textit{deadlock}}
2463 \label{sec:proc_race_cond}
2465 \index{\textit{race~condition}|(}
2466 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
2467 diversi operano su una risorsa comune, ed in cui il risultato viene a
2468 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
2469 tipico è quello di un'operazione che viene eseguita da un processo in più
2470 passi, e può essere compromessa dall'intervento di un altro processo che
2471 accede alla stessa risorsa quando ancora non tutti i passi sono stati
2474 Dato che in un sistema multitasking ogni processo può essere interrotto in
2475 qualunque momento per farne subentrare un altro in esecuzione, niente può
2476 assicurare un preciso ordine di esecuzione fra processi diversi o che una
2477 sezione di un programma possa essere eseguita senza interruzioni da parte di
2478 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
2479 difficili da tracciare, in quanto nella maggior parte dei casi tutto
2480 funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
2482 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
2483 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
2484 gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
2485 \textit{race condition} si hanno quando diversi processi accedono allo stesso
2486 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
2487 condivisa. In questi casi, se non si dispone della possibilità di eseguire
2488 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
2489 cui si compiono le operazioni sulle risorse condivise (le cosiddette
2490 \textsl{sezioni critiche}\index{sezioni~critiche}) del programma, siano
2491 opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
2492 problematiche di questo tipo in cap.~\ref{cha:IPC}).
2494 \index{\textit{deadlock}|(}
2495 Un caso particolare di \textit{race condition} sono poi i cosiddetti
2496 \textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
2497 completo di un servizio, e non il fallimento di una singola operazione. Per
2498 definizione un \textit{deadlock} è una situazione in cui due o più processi
2499 non sono più in grado di proseguire perché ciascuno aspetta il risultato di
2500 una operazione che dovrebbe essere eseguita dall'altro.
2503 L'esempio tipico di una situazione che può condurre ad un
2504 \textit{deadlock} è quello in cui un flag di
2505 ``\textsl{occupazione}'' viene rilasciato da un evento asincrono (come un
2506 segnale o un altro processo) fra il momento in cui lo si è controllato
2507 (trovandolo occupato) e la successiva operazione di attesa per lo sblocco. In
2508 questo caso, dato che l'evento di sblocco del flag è avvenuto senza che ce ne
2509 accorgessimo proprio fra il controllo e la messa in attesa, quest'ultima
2510 diventerà perpetua (da cui il nome di \textit{deadlock}).
2512 In tutti questi casi è di fondamentale importanza il concetto di atomicità
2513 visto in sez.~\ref{sec:proc_atom_oper}; questi problemi infatti possono essere
2514 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
2515 eseguire in maniera atomica le operazioni necessarie.
2516 \index{\textit{race~condition}|)}
2517 \index{\textit{deadlock}|)}
2520 \subsection{Le funzioni rientranti}
2521 \label{sec:proc_reentrant}
2523 Si dice \textsl{rientrante} una funzione che può essere interrotta in
2524 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
2525 un altro thread di esecuzione senza che questo comporti nessun problema
2526 nell'esecuzione della stessa. La problematica è comune nella programmazione
2527 multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare
2528 delle funzioni all'interno dei gestori dei segnali.
2530 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
2531 queste infatti vengono allocate nello stack, e un'altra invocazione non fa
2532 altro che allocarne un'altra copia. Una funzione può non essere rientrante
2533 quando opera su memoria che non è nello stack. Ad esempio una funzione non è
2534 mai rientrante se usa una variabile globale o statica.
2536 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
2537 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
2538 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
2539 esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
2540 potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
2541 Allo stesso modo una funzione può non essere rientrante se usa e modifica un
2542 oggetto che le viene fornito dal chiamante: due chiamate possono interferire
2543 se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
2544 parte del programmatore.
2546 In genere le funzioni di libreria non sono rientranti, molte di esse ad
2547 esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
2548 disposizione due macro di compilatore, \macro{\_REENTRANT} e
2549 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
2550 varie funzioni di libreria, che sono identificate aggiungendo il suffisso
2551 \code{\_r} al nome della versione normale.
2555 %%% Local Variables:
2557 %%% TeX-master: "gapil"