1 \chapter{Sessioni di lavoro e terminali}
4 Esamineremo in questo capitolo i concetti base del sistema delle sessioni di
5 lavoro, vale a dire il metodo con cui il kernel gestisce l'accesso concorrente
6 al sistema da parte di più utenti, permettendo loro di eseguire più programmi
7 in contemporanea. Nella seconda parte del capitolo tratteremo poi il
8 funzionamento dell'I/O su terminale, e delle varie peculiarità che esso viene
9 ad assumere a causa del suo stretto legame con le modalità di accesso al
10 sistema da parte degli utenti.
13 \section{Il \textit{job control}}
14 \label{sec:sess_job_control}
16 Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
17 il cui scopo è quello di permettere ad un utente di poter sfruttare le
18 capacità multitasking di un sistema Unix per eseguire in contemporanea più
19 processi, pur potendo accedere, di solito, ad un solo terminale,\footnote{con
20 X e con i terminali virtuali tutto questo non è più vero, dato che si può
21 accedere a molti terminali in contemporanea da una singola postazione di
22 lavoro, ma il sistema è nato prima dell'esistenza di tutto ciò.} avendo cioè
23 un solo punto in cui si può avere accesso all'input ed all'output degli
27 \subsection{Una panoramica introduttiva}
28 \label{sec:sess_job_control_overview}
30 Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
31 negli anni '80, e successivamente standardizzata da POSIX.1; la sua
32 disponibilità nel sistema è verificabile attraverso il controllo della macro
33 \macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
34 supporto sia da parte della shell (quasi tutte ormai lo fanno), che da parte
35 del kernel; in particolare il kernel deve assicurare sia la presenza di un
36 driver per i terminali abilitato al \textit{job control} che quella dei
37 relativi segnali illustrati in \secref{sec:sig_job_control}.
39 In un sistema che supporta il \textit{job control}, una volta completato il
40 login, l'utente avrà a disposizione una shell dalla quale eseguire i comandi e
41 potrà iniziare quella che viene chiamata una \textsl{sessione}, che riunisce
42 (vedi \secref{sec:sess_proc_group}) tutti i processi eseguiti all'interno
43 dello stesso login (esamineremo tutto il processo in dettaglio in
44 \secref{sec:sess_login}).
46 Siccome la shell è collegata ad un solo terminale, che viene usualmente
47 chiamato \textsl{terminale di controllo}, (vedi \secref{sec:sess_ctrl_term})
48 un solo comando alla volta (quello che viene detto in \textit{foreground}),
49 potrà scrivere e leggere dal terminale. La shell però può eseguire anche più
50 comandi in contemporanea, mandandoli in \textit{background} (aggiungendo una
51 \cmd{\&} alla fine del comando), nel qual caso essi saranno eseguiti senza
52 essere collegati al terminale.
54 Si noti come si sia parlato di comandi e non di programmi o processi; fra le
55 funzionalità della shell infatti c'è anche quella di consentire di concatenare
56 più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
57 eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
58 questo potrà sempre lanciare sottoprocessi per eseguire dei compiti specifici.
60 Per questo l'esecuzione di un comando può originare più di un processo; quindi
61 nella gestione del job control non si può far riferimento ai singoli processi.
62 Per questo il kernel prevede la possibilità di raggruppare più processi in un
63 \textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi
64 \secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
65 originano da una riga di comando appartengano allo stesso raggruppamento, in
66 modo che le varie funzioni di controllo, ed i segnali inviati dal terminale,
67 possano fare riferimento ad esso.
69 In generale allora all'interno di una sessione avremo un eventuale (può non
70 esserci) \textit{process group} in \textit{foreground}, che riunisce i
71 processi che possono accedere al terminale, e più \textit{process group} in
72 \textit{background}, che non possono accedervi. Il job control prevede che
73 quando un processo appartenente ad un raggruppamento in \textit{background}
74 cerca di accedere al terminale, venga inviato un segnale a tutti i processi
75 del raggruppamento, in modo da bloccarli (vedi \secref{sec:sess_ctrl_term}).
77 Un comportamento analogo si ha anche per i segnali generati dai comandi di
78 tastiera inviati dal terminale che vengono inviati a tutti i processi del
79 raggruppamento in \textit{foreground}. In particolare \cmd{C-z} interrompe
80 l'esecuzione del comando, che può poi essere mandato in \textit{background}
81 con il comando \cmd{bg}.\footnote{si tenga presente che \cmd{bg} e \cmd{fg}
82 sono parole chiave che indicano comandi interni alla shell, e nel caso non
83 comportano l'esecuzione di un programma esterno.} Il comando \cmd{fg}
84 consente invece di mettere in \textit{foreground} un comando precedentemente
85 lanciato in \textit{background}.
87 Di norma la shell si cura anche di notificare all'utente (di solito prima
88 della stampa a video del prompt) lo stato dei vari processi; essa infatti sarà
89 in grado, grazie all'uso di \func{waitpid}, di rilevare sia i processi che
90 sono terminati, sia i raggruppamenti che sono bloccati (in questo caso usando
91 l'opzione \macro{WUNTRACED}, secondo quanto illustrato in
92 \secref{sec:proc_wait}).
95 \subsection{I \textit{process group} e le \textsl{sessioni}}
96 \label{sec:sess_proc_group}
98 Come accennato in \secref{sec:sess_job_control_overview} nel job control i
99 processi vengono raggruppati in \textit{process group} e \textit{sessioni};
100 per far questo vengono utilizzati due ulteriori identificatori (oltre quelli
101 visti in \secref{sec:proc_pid}) che il kernel associa a ciascun
102 processo:\footnote{in Linux questi identificatori sono mantenuti nei campi
103 \var{pgrp} e \var{session} della struttura \var{task\_struct} definita in
104 \file{sched.h}.} l'identificatore del \textit{process group} e
105 l'identificatore della \textsl{sessione}, che vengono indicati rispettivamente
106 con le sigle \acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo
107 \type{pid\_t}. I valori di questi identificatori possono essere visualizzati
108 dal comando \cmd{ps} usando l'opzione \cmd{-j}.
110 Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
111 stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
112 le funzioni \func{getpgid} e \func{getpgrp},\footnote{\func{getpgrp} è
113 definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
114 i cui prototipi sono:
118 \funcdecl{pid\_t getpgid(pid\_t pid)}
119 Legge il \acr{pgid} del processo \param{pid}.
121 \funcdecl{pid\_t getpgrp(void)}
122 Legge il \acr{pgid} del processo corrente.
124 \bodydesc{Le funzioni restituiscono il \acr{pgid} del processo,
125 \func{getpgrp} ha sempre successo, mentre \func{getpgid} restituisce -1
126 ponendo \var{errno} a \macro{ESRCH} se il processo selezionato non esiste.}
129 La funzione \func{getpgid} permette di specificare il \acr{pid} del processo
130 di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
131 restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
132 equivalente a \code{getpgid(0)}.
134 In maniera analoga l'identificatore della sessione può essere letto dalla
135 funzione \func{getsid}, che però nelle \acr{glibc}\footnote{la system call è
136 stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
137 librerie del C è iniziato dalla versione 5.2.19. La funzione non è prevista
138 da POSIX.1, che parla solo di processi leader di sessione, e non di
139 identificatori di sessione.} è accessibile solo definendo
140 \macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}; il suo prototipo
142 \begin{prototype}{unistd.h}{pid\_t getsid(pid\_t pid)}
143 Legge l'identificatore di sessione del processo \param{pid}.
145 \bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
146 caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
149 \item[\macro{ESRCH}] Il processo selezionato non esiste.
150 \item[\macro{EPERM}] In alcune implementazioni viene restituito quando il
151 processo selezionato non fa parte della stessa sessione del processo
157 Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
158 processo con lo stesso valore che hanno nel processo padre, per cui un
159 processo appena creato appartiene sempre allo stesso raggruppamento e alla
160 stessa sessione del padre. Vedremo poi come sia possibile creare più
161 \textit{process group} all'interno della stessa sessione, e spostare i
162 processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
164 Ciascun raggruppamento di processi ha sempre un processo principale, il
165 cosiddetto \textit{process group leader}, che è identificato dall'avere un
166 \acr{pgid} uguale al suo \acr{pid}, in genere questo è il primo processo del
167 raggruppamento, che si incarica di lanciare tutti gli altri. Un nuovo
168 raggruppamento si crea con la funzione \func{setpgrp},\footnote{questa è la
169 definizione di POSIX.1, BSD definisce una funzione con lo stesso nome, che
170 però è identica a \func{setpgid}; nelle \acr{glibc} viene sempre usata
171 sempre questa definizione, a meno di non richiedere esplicitamente la
172 compatibilità all'indietro con BSD, definendo la macro
173 \macro{\_BSD\_SOURCE}.} il cui prototipo è:
174 \begin{prototype}{unistd.h}{int setpgrp(void)}
175 Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
177 \bodydesc{La funzione restituisce il valore del nuovo \textit{process
181 La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
182 corrente, rende questo \textit{group leader} di un nuovo raggruppamento, tutti
183 i successivi processi da esso creati apparterranno (a meno di non cambiare di
184 nuovo il \acr{pgid}) al nuovo raggruppamento. È possibile invece spostare un
185 processo da un raggruppamento ad un altro con la funzione \func{setpgid}, il
187 \begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
188 Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
190 \bodydesc{La funzione ritorna il valore del nuovo \textit{process group}, e
191 -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
193 \item[\macro{ESRCH}] Il processo selezionato non esiste.
194 \item[\macro{EPERM}] Il cambiamento non è consentito.
195 \item[\macro{EACCESS}] Il processo ha già eseguito una \func{exec}.
196 \item[\macro{EINVAL}] Il valore di \param{pgid} è negativo.
201 La funzione permette di cambiare il \acr{pgid} del processo \param{pid}, ma il
202 cambiamento può essere effettuato solo se \param{pgid} indica un
203 \textit{process group} che è nella stessa sessione del processo chiamante.
204 Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
205 dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha
206 ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
207 dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in
208 \var{task\_struct}.} Specificando un valore nullo per \param{pid} si indica
209 il processo corrente, mentre specificando un valore nullo per \param{pgid} si
210 imposta il \textit{process group} al valore del \acr{pid} del processo
211 selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0, 0)}.
213 Di norma questa funzione viene usata dalla shell quando si usano delle
214 pipeline, per mettere nello stesso process group tutti i programmi lanciati su
215 ogni linea di comando; essa viene chiamata dopo una \func{fork} sia dal
216 processo padre, per impostare il valore nel figlio, che da quest'ultimo, per
217 sé stesso, in modo che il cambiamento di \textit{process group} sia immediato
218 per entrambi; una delle due chiamate sarà ridondante, ma non potendo
219 determinare quale dei due processi viene eseguito per primo, occorre eseguirle
220 comunque entrambe per evitare di esporsi ad una race condition.
222 Si noti come nessuna delle funzioni esaminate finora permetta di spostare un
223 processo da una sessione ad un altra; infatti l'unico modo di far cambiare
224 sessione ad un processo è quello di crearne una nuova con l'uso di
225 \func{setsid}; il suo prototipo è:
226 \begin{prototype}{unistd.h}{pid\_t setsid(void)}
227 Crea una nuova sessione sul processo corrente impostandone \acr{sid} e
230 \bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di
231 errore, il solo errore possibile è \macro{EPERM}, che si ha quando il
232 \acr{pgid} e \acr{pid} del processo coincidono.}
235 La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
236 valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo
237 \textit{process group} di cui esso diventa leader (come per i \textit{process
238 group} un processo si dice leader di sessione\footnote{in Linux la proprietà
239 è mantenuta in maniera indipendente con un apposito campo \var{leader} in
240 \var{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed unico
241 componente. Inoltre la funzione distacca il processo da ogni terminale di
242 controllo (torneremo sull'argomento in \secref{sec:sess_ctrl_term}) cui fosse
243 in precedenza associato.
245 funzione ha successo soltanto se il processo non è già leader di un
246 \textit{process group}, per cui per usarla di norma si esegue una \func{fork}
247 e si esce, per poi chiamare \func{setsid} nel processo figlio, in modo che,
248 avendo questo lo stesso \acr{pgid} del padre ma un \acr{pid} diverso, non ci
249 siano possibilità di errore.\footnote{potrebbe sorgere il dubbio che, per il
250 riutilizzo dei valori dei \acr{pid} fatto nella creazione dei nuovi processi
251 (vedi \secref{sec:proc_pid}), il figlio venga ad assumere un valore
252 corrispondente ad un process group esistente; questo viene evitato dal
253 kernel che considera come disponibili per un nuovo \acr{pid} solo valori che
254 non corrispondono ad altri \acr{pid}, \acr{pgid} o \acr{sid} in uso nel
255 sistema.} Questa funzione viene usata di solito nel processo di login (per i
256 dettagli vedi \secref{sec:sess_login}) per raggruppare in una sessione tutti i
257 comandi eseguiti da un utente dalla sua shell.
261 \subsection{Il terminale di controllo e il controllo di sessione}
262 \label{sec:sess_ctrl_term}
264 Come accennato in \secref{sec:sess_job_control_overview}, nel sistema del
265 \textit{job control} i processi all'interno di una sessione fanno riferimento
266 ad un terminale di controllo (ad esempio quello su cui si è effettuato il
267 login), sul quale effettuano le operazioni di lettura e
268 scrittura,\footnote{nel caso di login grafico la cosa può essere più
269 complessa, e di norma l'I/O è effettuato tramite il server X, ma ad esempio
270 per i programmi, anche grafici, lanciati da un qualunque emulatore di
271 terminale, sarà quest'ultimo a fare da terminale (virtuale) di controllo.} e
272 dal quale ricevono gli eventuali segnali da tastiera.
274 A tale scopo lo standard POSIX.1 prevede che ad ogni sessione possa essere
275 associato un terminale di controllo; in Linux questo viene realizzato
276 mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
277 di controllo. \footnote{Lo standard POSIX.1 non specifica nulla riguardo
278 l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura
279 \var{task\_struct}, nel campo \var{tty}.} In generale ogni processo eredita
280 dal padre, insieme al \acr{pgid} e al \acr{sid} anche il terminale di
281 controllo (vedi \secref{sec:proc_fork}). In questo modo tutti processi
282 originati dallo stesso leader di sessione mantengono lo stesso terminale di
285 Alla creazione di una nuova sessione con \func{setsid} ogni associazione con
286 il precedente terminale di controllo viene cancellata, ed il processo che è
287 divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
288 è necessario, cosa che, come vedremo in \secref{sec:sess_daemon}, non è
289 sempre vera.}, un terminale di controllo. In generale questo viene fatto
290 automaticamente dal sistema\footnote{a meno di non avere richiesto
291 esplicitamente che questo non diventi un terminale di controllo con il flag
292 \macro{O\_NOCTTY} (vedi \secref{sec:file_open}). In questo Linux segue la
293 semantica di SVr4; BSD invece richiede che il terminale venga allocato
294 esplicitamente con una \func{ioctl} con il comando \macro{TIOCSCTTY}.}
295 quando viene aperto il primo terminale (cioè uno dei vari file di dispositivo
296 \file{/dev/tty*}) che diventa automaticamente il terminale di controllo,
297 mentre il processo diventa il \textsl{processo di controllo} di quella
300 In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
301 associato ai file standard (di input, output ed error) dei processi nella
302 sessione, ma solo quelli che fanno parte del cosiddetto raggruppamento di
303 \textit{foreground}, possono leggere e scrivere in certo istante. Per
304 impostare il raggruppamento di \textit{foreground} di un terminale si usa la
305 funzione \func{tcsetpgrp}, il cui prototipo è:
310 \funcdecl{int tcsetpgrp(int fd, pid\_t pgrpid)} Imposta a \param{pgrpid} il
311 \textit{process group} di \textit{foreground} del terminale associato al
312 file descriptor \param{fd}.
314 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
315 errore, nel qual caso \var{errno} assumerà i valori:
317 \item[\macro{ENOTTY}] Il file \param{fd} non corrisponde al terminale di
318 controllo del processo chiamante.
319 \item[\macro{ENOSYS}] Il sistema non supporta il job control.
320 \item[\macro{EPERM}] Il \textit{process group} specificato non è nella
321 stessa sessione del processo chiamante.
323 ed inoltre \macro{EBADF} ed \macro{EINVAL}.
326 \noindent la funzione può essere eseguita con successo solo da
327 un processo nella stessa sessione e con lo stesso terminale di controllo.
329 Come accennato in \secref{sec:sess_job_control_overview}, tutti i processi (e
330 relativi raggruppamenti) che non fanno parte del gruppo di \textit{foreground}
331 sono detti in \textit{background}; se uno si essi cerca di accedere al
332 terminale di controllo provocherà l'invio da parte del kernel di uno dei due
333 segnali \macro{SIGTTIN} o \macro{SIGTTOU} (a seconda che l'accesso sia stato
334 in lettura o scrittura) a tutto il suo \textit{process group}; dato che il
335 comportamento di default di questi segnali (si riveda quanto esposto in
336 \secref{sec:sig_job_control}) è di fermare il processo, di norma questo
337 comporta che tutti i membri del gruppo verranno fermati, ma non si avranno
338 condizioni di errore.\footnote{la shell in genere notifica comunque un
339 avvertimento, avvertendo la presenza di processi bloccati grazie all'uso di
340 \func{waitpid}.} Se però si bloccano o ignorano i due segnali citati, le
341 funzioni di lettura e scrittura falliranno con un errore di \macro{EIO}.
343 Un processo può controllare qual'è il gruppo di \textit{foreground} associato
344 ad un terminale con la funzione \func{tcgetpgrp}, il cui prototipo è:
346 \headdecl{unistd.h} \headdecl{termios.h}
348 \funcdecl{pid\_t tcgetpgrp(int fd)} Legge il \textit{process group} di
349 \textit{foreground} del terminale associato al file descriptor \param{fd}.
350 \bodydesc{La funzione restituisce in caso di successo il \acr{pgid} del
351 gruppo di \textit{foreground}, e -1 in caso di errore, nel qual caso
352 \var{errno} assumerà i valori:
354 \item[\macro{ENOTTY}] Non c'è un terminale di controllo o \param{fd} non
355 corrisponde al terminale di controllo del processo chiamante.
357 ed inoltre \macro{EBADF} ed \macro{ENOSYS}.
361 Si noti come entrambe le funzioni usino come argomento il valore di un file
362 descriptor, il risultato comunque non dipende dal file descriptor che si usa
363 ma solo dal terminale cui fa riferimento; il kernel inoltre permette a ciascun
364 processo di accedere direttamente al suo terminale di controllo attraverso il
365 file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il
366 proprio terminale di controllo. Questo consente anche a processi che possono
367 aver rediretto l'output di accedere al terminale di controllo, pur non
368 disponendo più del file descriptor originario; un caso tipico è il programma
369 \cmd{crypt} che accetta la redirezione sullo standard input di un file da
370 decifrare, ma deve poi leggere la password dal terminale.
372 Un'altra caratteristica del terminale di controllo usata nel job control è che
373 utilizzando su di esso le combinazioni di tasti speciali (\cmd{C-z},
374 \cmd{C-c}, \cmd{C-y} e \verb|C-\|) si farà sì che il kernel invii i
375 corrispondenti segnali (rispettivamente \macro{SIGTSTP}, \macro{SIGINT},
376 \macro{SIGQUIT} e \macro{SIGTERM}, trattati in \secref{sec:sig_job_control}) a
377 tutti i processi del raggruppamento di \textit{foreground}; in questo modo la
378 shell può gestire il blocco e l'interruzione dei vari comandi.
380 Per completare la trattazione delle caratteristiche del job control legate al
381 terminale di controllo, occorre prendere in considerazione i vari casi legati
382 alla terminazione anomala dei processi, che sono di norma gestite attraverso
383 il segnale \macro{SIGHUP}. Il nome del segnale deriva da \textit{hungup},
384 termine che viene usato per indicare la condizione in cui il terminale diventa
385 inutilizzabile, (letteralmente sarebbe \textsl{impiccagione}).
387 Quando si verifica questa condizione, ad esempio se si interrompe la linea, o
388 va giù la rete o più semplicemente si chiude forzatamente la finestra di
389 terminale su cui si stava lavorando, il kernel provvederà ad inviare il
390 segnale di \macro{SIGHUP} al processo di controllo. L'azione preimpostata in
391 questo caso è la terminazione del processo, il problema che si pone è cosa
392 accade agli altri processi nella sessione, che non han più un processo di
393 controllo che possa gestire l'accesso al terminale, che potrebbe essere
394 riutilizzato per qualche altra sessione.
396 Lo standard POSIX.1 prevede che quando il processo di controllo termina, che
397 ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si
398 potrebbe terminare direttamente la shell con \cmd{kill}) venga inviato un
399 segnale di \macro{SIGHUP} ai processi del raggruppamento di foreground. In
400 questo modo essi potranno essere avvisati che non esiste più un processo in
401 grado di gestire il terminale (di norma tutto ciò comporta la terminazione
402 anche di questi ultimi).
404 Restano però gli eventuali processi in background, che non ricevono il
405 segnale; in effetti se il terminale non dovesse più servire essi potrebbero
406 proseguire fino al completamento della loro esecuzione; ma si pone il problema
407 di come gestire quelli che sono bloccati, o che si bloccano nell'accesso al
408 terminale, in assenza di un processo che sia in grado di effettuare il
409 controllo dello stesso.
411 Questa è la situazione in cui si ha quello che viene chiamato un
412 \textit{orphaned process group}. Lo standard POSIX.1 lo definisce come un
413 \textit{process group} i cui processi hanno come padri esclusivamente o altri
414 processi nel raggruppamento, o processi fuori della sessione. Lo standard
415 prevede inoltre che se la terminazione di un processo fa sì che un
416 raggruppamento di processi diventi orfano e se i suoi membri sono bloccati, ad
417 essi vengano inviati in sequenza i segnali di \macro{SIGHUP} e
420 La definizione può sembrare complicata, e a prima vista non è chiaro cosa
421 tutto ciò abbia a che fare con il problema della terminazione del processo di
422 controllo. Consideriamo allora cosa avviene di norma nel \textit{job
423 control}: una sessione viene creata con \func{setsid} che crea anche un
424 nuovo process group: per definizione quest'ultimo è sempre \textsl{orfano},
425 dato che il padre del leader di sessione è fuori dalla stessa e il nuovo
426 process group contiene solo il leader di sessione. Questo è un caso limite, e
427 non viene emesso nessun segnale perché quanto previsto dallo standard riguarda
428 solo i raggruppamenti che diventano orfani in seguito alla terminazione di un
429 processo.\footnote{l'emissione dei segnali infatti avviene solo nella fase di
430 uscita del processo, come una delle operazioni legate all'esecuzione di
431 \func{\_exit}, secondo quanto illustrato in \secref{sec:proc_termination}.}
433 Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
434 punto non sono orfani in quanto esso resta padre per almeno uno dei processi
435 del gruppo (gli altri possono derivare dal primo). Alla terminazione del
436 leader di sessione però avremo che, come visto in
437 \secref{sec:proc_termination}, tutti i suoi figli vengono adottati da
438 \cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process
439 group creati direttamente dal leader di sessione (a meno di non aver spostato
440 con \func{setpgid} un processo da un gruppo ad un altro, cosa che di norma non
441 viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali;
442 \macro{SIGCONT} ne farà proseguire l'esecuzione, ed essendo stato nel
443 frattempo inviato anche \macro{SIGHUP}, se non c'è un gestore per
444 quest'ultimo, i processi bloccati verranno automaticamente terminati.
448 \subsection{Dal login alla shell}
449 \label{sec:sess_login}
451 L'organizzazione del sistema del job control è strettamente connessa alle
452 modalità con cui un utente accede al sistema per dare comandi, collegandosi ad
453 esso con un terminale, che sia questo realmente tale, come un VT100 collegato
454 ad una seriale o virtuale, come quelli associati a schermo e tastiera o ad una
455 connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
456 fine le differenze sono\footnote{in generale nel caso di login via rete o di
457 terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
458 ha origine l'esecuzione della shell.} nel dispositivo cui il kernel associa i
459 file standard (vedi \secref{sec:file_std_descr}) per l'I/O, tratteremo solo il
460 caso classico del terminale.
462 Abbiamo già brevemente illustrato in \secref{sec:intro_kern_and_sys} le
463 modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
464 vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
465 dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
466 shell che gli permette di lanciare i suoi comandi su un terminale.
468 Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
469 distribuzione \textit{Slackware}, come alcune distribuzioni su dischetto, ed
470 altre distribuzioni dedicate a compiti limitati e specifici.} viene usata
471 la procedura di avvio di System V; questa prevede che \cmd{init} legga dal
472 file di configurazione \file{/etc/inittab} quali programmi devono essere
473 lanciati, ed in quali modalità, a seconda del cosiddetto \textit{run level},
474 anch'esso definito nello stesso file.
476 Tralasciando la descrizione del sistema dei run level, (per il quale si
477 rimanda alla lettura delle pagine di manuale di \cmd{init} e di
478 \file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno
479 una istanza di un programma che permetta l'accesso ad un terminale. Uno schema
480 di massima della procedura è riportato in \figref{fig:sess_term_login}.
484 \includegraphics[width=15cm]{img/tty_login}
485 \caption{Schema della procedura di login su un terminale.}
486 \label{fig:sess_term_login}
489 Un terminale, che esso sia un terminale effettivo, attaccato ad una seriale o
490 ad un altro tipo di porta di comunicazione, o una delle console virtuali
491 associate allo schermo, viene sempre visto attraverso attraverso un device
492 driver che ne presenta un'interfaccia comune su un apposito file di
493 dispositivo. Storicamente i primi terminali erano appunto terminali di
494 telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia,
495 \textit{tty}, che quello dei relativi file di dispositivo, che sono sempre
496 della forma \texttt{/dev/tty*}.\footnote{questo vale anche per i terminali
497 virtuali associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
499 Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
500 delle sue varianti), che permette di mettersi in ascolto su uno di questi
501 dispositivi. Alla radice della catena che porta ad una shell per i comandi
502 perciò c'è sempre \cmd{init} che esegue prima una \func{fork} e poi una
503 \func{exec} per lanciare una istanza di questo programma su un terminale, il
504 tutto ripetuto per ciascuno dei terminali che si hanno a disposizione (o per
505 un certo numero di essi, nel caso delle console virtuali), secondo quanto
506 indicato dall'amministratore nel file di configurazione del programma,
509 Quando viene lanciato da \cmd{init} il programma parte con i privilegi di
510 amministratore e con un ambiente vuoto; \cmd{getty} si cura di chiamare
511 \func{setsid} per creare una nuova sessione ed un nuovo process group, e di
512 aprire il terminale (che così diventa il terminale di controllo della
513 sessione) in lettura sullo standard input ed in scrittura sullo standard
514 output e sullo standard error; inoltre effettuerà, qualora servano, ulteriori
515 settaggi.\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
516 di login in maiuscolo, può effettuare la conversione automatica dell'input
517 in minuscolo, ponendosi in una modalità speciale che non distingue fra i due
518 tipi di caratteri (a beneficio di alcuni vecchi terminali che non
519 supportavano le minuscole).} Alla fine il programma stamperà un messaggio di
520 benvenuto per poi porsi in attesa dell'immissione del nome di un utente.
522 Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
523 il programma \cmd{login} con una \func{exevle}, passando come argomento la
524 stringa con il nome, ed un ambiente opportunamente costruito che contenga
525 quanto necessario (ad esempio di solito viene opportunamente inizializzata la
526 variabile di ambiente \texttt{TERM}) ad identificare il terminale su cui si
527 sta operando, a beneficio dei programmi che verranno lanciati in seguito.
529 A sua volta \cmd{login}, che mantiene i privilegi di amministratore, usa il
530 nome dell'utente per effettuare una ricerca nel database degli
531 utenti,\footnote{in genere viene chiamata \func{getpwnam}, che abbiamo visto
532 in \secref{sec:sys_user_group}, per leggere la password e gli altri dati dal
533 database degli utenti.} e richiede una password. Se l'utente non esiste o se
534 la password non corrisponde\footnote{il confronto non viene effettuato con un
535 valore in chiaro; quanto immesso da terminale viene invece a sua volta
536 criptato, ed è il risultato che viene confrontato con il valore che viene
537 mantenuto nel database degli utenti.} la richiesta viene ripetuta un certo
538 numero di volte dopo di che \cmd{login} esce ed \cmd{init} provvede a
539 rilanciare un'altra istanza di \func{getty}.
541 Se invece la password corrisponde \cmd{login} esegue \func{chdir} per settare
542 la \textit{home directory} dell'utente, cambia i diritti di accesso al
543 terminale (con \func{chown} e \func{chmod}) per assegnarne la titolarità
544 all'utente ed al suo gruppo principale, assegnandogli al contempo i diritti di
545 lettura e scrittura. Inoltre il programma provvede a costruire gli opportuni
546 valori per le variabili di ambiente, come \texttt{HOME}, \texttt{SHELL}, ecc.
547 Infine attraverso l'uso di \func{setuid}, \func{setpid} e \func{initgroups}
548 verrà cambiata l'identità del proprietario del processo, infatti, come
549 spiegato in \secref{sec:proc_setuid}, avendo invocato tali funzioni con i
550 privilegi di amministratore, tutti gli userid ed i groupid (reali, effettivi e
551 salvati) saranno settati a quelli dell'utente.
553 A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
554 iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
555 ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
556 già pronto con i file standard di \secref{sec:file_std_descr} impostati sul
557 terminale, e pronta, nel ruolo di leader di sessione e processo di controllo
558 per il terminale, a gestire l'esecuzione dei comandi come illustrato in
559 \secref{sec:sess_job_control_overview}. Dato che il processo padre resta
560 sempre \cmd{init} quest'ultimo potrà provvedere, ricevendo un \macro{SIGCHLD}
561 all'uscita della shell, a rilanciare \cmd{getty} sul terminale per ripetere da
562 capo tutto il procedimento.
566 \subsection{Prescrizioni per un programma \textit{daemon}}
567 \label{sec:sess_daemon}
569 Come sottolineato fin da \secref{sec:intro_base_concept}, in un sistema
570 unix-like tutte le operazioni sono eseguite tramite processi, comprese quelle
571 operazioni di sistema (come l'esecuzione di comandi periodici, o la consegna
572 della posta, ed in generale tutti i programmi di servizio) che non hanno a che
573 fare con la gestione diretta dei comandi dell'utente.
575 Questi programmi, che devono essere eseguiti in modalità non interattiva senza
576 nessun intervento dell'utente, sono normalmente chiamati \textsl{demoni}, (o
577 \textit{daemons}), nome ispirato dagli omonimi spiritelli che svolgevano vari
578 compiti, di cui parlava Socrate (che sosteneva di averne uno al suo
579 servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia sono
585 \section{L'I/O su terminale}
586 \label{sec:sess_terminal_io}
588 Esamineremo in questa sezione le peculiarità dell'I/O eseguito sui terminali,
589 tenendo conto delle differenze che quest'ultimi presentano rispetto ai normali
597 %%% TeX-master: "gapil"