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, ma il sistema è nato prima
22 dell'esistenza di tutto ciò.} avendo cioè un solo punto in cui si può avere
23 accesso all'input ed all'output degli stessi.
26 \subsection{Una panoramica introduttiva}
27 \label{sec:sess_job_control_overview}
29 Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
30 negli anni '80, e successivamente standardizzata da POSIX.1; la sua
31 disponibilità nel sistema è verificabile attraverso il controllo della macro
32 \macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
33 supporto sia da parte della shell (quasi tutte ormai lo fanno), che da parte
34 del kernel; in particolare il kernel deve assicurare sia la presenza di un
35 driver per i terminali abilitato al \textit{job control} che quella dei
36 relativi segnali illustrati in \secref{sec:sig_job_control}.
38 In un sistema che supporta il \textit{job control} una volta completato il
39 login (che esamineremo in dettaglio in \secref{sec:sess_login}), l'utente avrà
40 a disposizione una shell dalla quale eseguire i comandi e potrà iniziare
41 quella che viene chiamata una \textsl{sessione}, che riunisce (vedi
42 \secref{sec:sess_proc_group}) tutti i processi eseguiti all'interno dello
45 Siccome la shell è collegata ad un solo terminale (che viene usualmente
46 chiamato \textsl{terminale di controllo}) un solo comando alla volta (quello
47 che viene detto in \textit{foreground}), potrà scrivere e leggere dal
48 terminale. La shell però può eseguire anche più comandi in contemporanea,
49 mandandoli in \textit{background} (aggiungendo una \cmd{\&} alla fine del
50 comando), nel qual caso essi saranno eseguiti senza essere collegati al
53 Si noti come si sia parlato di comandi e non di programmi o processi; fra le
54 funzionalità della shell infatti c'è anche quella di consentire di concatenare
55 più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
56 eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
57 questo potrà sempre lanciare sottoprocessi per eseguire dei compiti specifici.
59 Per questo l'esecuzione di un comando può originare più di un processo; quindi
60 nella gestione del job control non si può far riferimento ai singoli processi.
61 Per questo il kernel prevede la possibilità di raggruppare più processi in un
62 \textit{process group} (detto anche \textsl{raggruppamento}, vedi
63 \secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
64 originano da una riga di comando appartengano allo stesso \textit{process
65 group}, in modo che le varie funzioni di controllo, ed i segnali inviati dal
66 terminale, possano fare riferimento ad esso.
68 In generale allora all'interno di una sessione avremo un eventuale (possono
69 non esserci) \textit{process group} in \textit{foreground}, che riunisce i
70 processi che possono accedere al terminale, e più \textit{process group} in
71 \textit{background}, che non possono accedervi. Il job control prevede che
72 quando un processo appartenente ad un raggruppamento in \textit{background}
73 cerca di accedere al terminale questo invii a tutti i processi del
74 raggruppamento un segnale di \macro{SIGTTIN} o di \macro{SIGTTOU}, a seconda
75 che l'accesso sia rispettivamente in lettura o scrittura, bloccando (secondo
76 il comportamento di default esposto in \secref{sec:sig_job_control}) i
79 Un comportamento analogo si ha anche per i segnali generati dai comandi di
80 tastiera inviati dal terminale con \cmd{C-z}, \cmd{C-c}, \cmd{C-y} e
81 \verb|C-\|; questi generano rispettivamente i segnali \macro{SIGTSTP},
82 \macro{SIGINT}, \macro{SIGQUIT} e \macro{SIGTERM}, che vengono inviati a tutti
83 i processi del raggruppamento in \textit{foreground}. In particolare il primo
84 di essi, \macro{SIGTSTP}, interrompe l'esecuzione del comando, che può poi
85 essere mandato in \textit{background} con il comando \cmd{bg}. Il comando
86 \cmd{fg} consente invece di mettere in \textit{foreground} un comando
87 precedentemente lanciato in \textit{background}.
89 Di norma la shell si cura anche di notificare all'utente (di solito prima
90 della stampa a video del prompt) lo stato dei vari processi, essa infatti usa
91 le caratteristiche della funzione \func{waitpid} (si riveda quanto detto in
92 \secref{sec:proc_wait}) per verificare quali gruppi di processi sono bloccati
93 e quali sono terminati.
96 \subsection{I \textit{process group} e le \textsl{sessioni}}
97 \label{sec:sess_proc_group}
99 Come accennato in \secref{sec:sess_job_control_overview} nel job control i
100 processi vengono raggruppati in \textit{process group} e \textit{sessioni};
101 per far questo vengono utilizzati due ulteriori identificatori (oltre quelli
102 visti in \secref{sec:proc_pid}) che il kernel associa a ciascun processo:
103 l'identificatore del \textit{process group} e l'identificatore della
104 \textsl{sessione}, che vengono indicati rispettivamente con le sigle
105 \acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo \type{pid\_t}. I
106 valori di questi identificatori possono essere visualizzati dal comando
107 \cmd{ps} usando l'opzione \cmd{-j}.
109 Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
110 stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
111 le funzioni \func{getpgid} e \func{getpgrp},\footnote{\func{getpgrp} è
112 definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
113 i cui prototipi sono:
117 \funcdecl{pid\_t getpgid(pid\_t pid)}
118 Legge il \acr{pgid} del processo \param{pid}.
120 \funcdecl{pid\_t getpgrp(void)}
121 Legge il \acr{pgid} del processo corrente.
123 \bodydesc{Le funzioni restituiscono il \acr{pgid} del processo,
124 \func{getpgrp} ha sempre successo, mentre \func{getpgid} restituisce -1
125 ponendo \var{errno} a \macro{ESRCH} se il processo selezionato non esiste.}
128 La funzione \func{getpgid} permette di specificare il \acr{pid} del processo
129 di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
130 restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
131 equivalente a \code{getpgid(0)}.
133 In maniera analoga l'identificatore della sessione può essere letto dalla
134 funzione \func{getsid}, che però nelle \acr{glibc}\footnote{la system call è
135 stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
136 librerie del C è iniziato dalla versione 5.2.19. La funzione non è prevista
137 da POSIX.1, che parla solo di processi leader di sessione, e non di
138 identificatori di sessione.} è accessibile solo definendo
139 \macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}; il suo prototipo
141 \begin{prototype}{unistd.h}{pid\_t getsid(pid\_t pid)}
142 Legge l'identificatore di sessione del processo \param{pid}.
144 \bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
145 caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
148 \item[\macro{ESRCH}] Il processo selezionato non esiste.
149 \item[\macro{EPERM}] In alcune implementazioni viene restituito quando il
150 processo selezionato non fa parte della stessa sessione del processo
156 Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
157 processo con lo stesso valore che hanno nel processo padre, per cui un
158 processo appena creato appartiene sempre allo stesso raggruppamento e alla
159 stessa sessione del padre. Vedremo poi come sia possibile creare più
160 \textit{process group} all'interno della stessa sessione, e spostare i
161 processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
163 Ciascun gruppo di processi ha sempre un processo principale, il cosiddetto
164 \textit{process group leader}, che è identificato dall'avere un \acr{pgid}
165 uguale al suo \acr{pid}, in genere questo è il primo processo del gruppo, che
166 si incarica di lanciare tutti gli altri. Un nuovo gruppo si crea con la
167 funzione \func{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD
168 definisce una funzione con lo stesso nome, che però è identica a
169 \func{setpgid}; nelle \acr{glibc} viene sempre usata sempre questa
170 definizione, a meno di non richiedere esplicitamente la compatibilità
171 all'indietro con BSD, definendo la macro \macro{\_BSD\_SOURCE}.} il cui
173 \begin{prototype}{unistd.h}{int setpgrp(void)}
174 Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
176 \bodydesc{La funzione restituisce il valore del nuovo \textit{process
180 La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
181 corrente, rende questo \textit{process leader} di un nuovo gruppo, tutti i
182 successivi processi da esso creati apparterranno (a meno di non cambiare di
183 nuovo il \acr{pgid}) al nuovo gruppo. È possibile invece spostare un processo
184 da un gruppo ad un altro con la funzione \func{setpgid}, il cui prototipo è:
185 \begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
186 Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
188 \bodydesc{La funzione ritorna il valore del nuovo \textit{process group}, e
189 -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
191 \item[\macro{ESRCH}] Il processo selezionato non esiste.
192 \item[\macro{EPERM}] Il cambiamento non è consentito.
193 \item[\macro{EINVAL}] Il valore di \param{pgid} è negativo.
198 La funzione permette di cambiare il \acr{pgid} del processo \param{pid}, ma il
199 cambiamento può essere effettuato solo se \param{pgid} indica un
200 \textit{process group} che è nella stessa sessione del processo chiamante.
201 Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
202 dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha
203 ancora eseguito una \func{exec}. Specificando un valore nullo per \param{pid}
204 si indica il processo corrente, mentre specificando un valore nullo per
205 \param{pgid} si imposta il \textit{process group} al valore del \acr{pid} del
206 processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
209 Di norma questa funzione viene usata dalla shell quando si usano delle
210 pipeline, per mettere nello stesso process group tutti i programmi lanciati su
211 ogni linea di comando; essa viene chiamata dopo una \func{fork} sia dal
212 processo padre, per impostare il valore nel figlio, che da quest'ultimo, per
213 sé stesso, in modo che il cambiamento di \textit{process group} sia immediato
214 per entrambi; una delle due chiamate sarà ridondante, ma non potendo
215 determinare quale dei due processi viene eseguito per primo, occorre eseguirle
216 comunque entrambe per evitare di esporsi ad una race condition.
218 Si noti come nessuna delle funzioni esaminate finora permetta di spostare un
219 processo da una sessione ad un altra; infatti l'unico modo di far cambiare
220 sessione ad un processo è quello di crearne una nuova con l'uso di
221 \func{setsid}; il suo prototipo è:
222 \begin{prototype}{unistd.h}{pid\_t setsid(void)}
223 Crea una nuova sessione sul processo corrente settandone \acr{sid} e
226 \bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di
227 errore, il solo errore possibile è \macro{EPERM}, che si ha quando il
228 \acr{pgid} e \acr{pid} del processo concidono.}
231 La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
232 valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo
233 \textit{process group} di cui esso diventa leader (come per i \textit{process
234 group} un processo si dice leader di sessione se il suo \acr{sid} è uguale
235 al suo \acr{pid}). Inoltre il processo non avrà più un terminale di
238 La funzione ha successo soltanto se il processo non è già leader per un
239 \textit{process group}, per cui per usarla di norma si esegue una \func{fork}
240 e si esce, per poi chiamare \func{setsid} nel processo figlio, in modo che,
241 avendo questo lo stesso \acr{pgid} del padre ma un \acr{pid} diverso, non ci
242 siano possibilità di errore. Questa funzione viene usata di solito nel
243 processo di login (per i dettagli vedi \secref{sec:sess_login}) per
244 raggruppare in una sessione tutti i comandi eseguiti da un utente dalla sua
249 \subsection{Il terminale di controllo}
250 \label{sec:sess_ctrl_term}
252 Come accennato in \secref{sec:sess_job_control_overview} ad ogni sessione di
253 lavoro di norma viene associato un terminale di controllo. Alla creazione
254 della sessione con \func{setsid} infatti ogni associazione con un precedente
255 terminale di controllo viene spezzata, ed il processo dovrà riottenere (se
256 necessario, vedi \secref{sec:sess_daemon}), un terminale di controllo.
261 \subsection{Dal login alla shell}
262 \label{sec:sess_login}
264 L'organizzazione del sistema del job control è strettamente connessa alle
265 modalità con cui un utente accede al sistema per dare comandi, collegandosi ad
266 esso con un terminale, che sia questo realmente tale, come un VT100 collegato
267 ad una seriale o virtuale, come quelli associati a schermo e tastiera o ad una
268 connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
269 fine le differenze sono\footnote{in generale nel caso di login via rete o di
270 terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
271 ha origine l'esecuzione della shell.} nel device cui il kernel associa i
272 file standard (vedi \secref{sec:file_std_descr}) per l'I/O, tratteremo solo il
273 caso classico del terminale.
275 Abbiamo già brevemente illustrato in \secref{sec:intro_kern_and_sys} le
276 modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
277 vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
278 dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
279 shell che gli permette di lanciare i suoi comandi su un terminale.
281 Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
282 distribuzione \textit{Slackware}, come alcune distribuzioni su dischetto, ed
283 altre distribuzioni dedicate a compiti limitati e specifici.} viene usata
284 la procedura di avvio di System V; questa prevede che \cmd{init} legga dal
285 file di configurazione \file{/etc/inittab} quali programmi devono essere
286 lanciati, ed in quali modalità, a seconda del cosiddetto \textit{run level},
287 anch'esso definito nello stesso file.
289 Tralasciando la descrizione del sistema dei run level, (per il quale si
290 rimanda alla lettura delle pagine di manuale di \cmd{init} e di
291 \file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno
292 una istanza di un programma che permetta l'accesso ad un terminale. Uno schema
293 di massima della procedura è riportato in \figref{fig:sess_term_login}.
297 \includegraphics[width=15cm]{img/tty_login}
298 \caption{Schema della procedura di login su un terminale.}
299 \label{fig:sess_term_login}
302 Un terminale, che esso sia un terminale effettivo, attaccato ad una seriale o
303 ad un altro tipo di porta di comunicazione, o una delle console virtuali
304 associate allo schermo, viene sempre visto attraverso attraverso un device
305 driver che ne presenta un'interfaccia comune su un apposito file di
306 dispositivo. Storicamente i primi terminali erano appunto terminali di
307 telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia,
308 \textit{tty}, che quello dei relativi file di dispositivo, che sono sempre
309 della forma \texttt{/dev/tty*}.\footnote{questo vale anche per i terminali
310 vitruali associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
312 Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
313 delle sue varianti), che permette di mettersi in ascolto su uno di questi
314 dispositivi. Alla radice della catena che porta ad una shell per i comandi
315 perciò c'è sempre \cmd{init} che esegue prima una \func{fork} e poi una
316 \func{exec} per lanciare una istanza di questo programma su un terminale, il
317 tutto ripetuto per ciascuno dei terminali che si hanno a disposizione (o per
318 un certo numero di essi, nel caso delle console virtuali), secondo quanto
319 indicato dall'amministratore nel file di configurazione del programma,
322 Quando viene lanciato da \cmd{init} il programma parte con i privilegi di
323 amministratore e con un ambiente vuoto; \cmd{getty} si cura di chiamare
324 \func{setsid} per creare una nuova sessione ed un nuovo process group, e di
325 aprire il terminale (che così diventa il terminale di controllo della
326 sessione) in lettura sullo standard input ed in scrittura sullo standard
327 output e sullo standard error; inoltre effettuarà, qualora servano, ulteriori
328 settaggi.\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
329 di login in maiuscolo, può effettuare la conversione automatica dell'input
330 in minuscolo, ponendosi in una modalità speciale che non distingue fra i due
331 tipi di caratteri (a beneficio di alcuni vecchi terminali che non
332 supportavano le minuscole).} Alla fine il programma stamperà un messaggio di
333 benvenuto per poi porsi in attesa dell'immissione del nome di un utente.
335 Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
336 il programma \cmd{login} con una \func{exevle}, passando come argomento la
337 stringa con il nome, ed un ambiente opportunamente costruito che contenga
338 quanto necessario (ad esempio di solito viene opportunamente inizializzata la
339 variabile di ambiente \texttt{TERM}) ad identificare il terminale su cui si
340 sta operando, a beneficio dei programmi che verranno lanciati in seguito.
342 A sua volta \cmd{login}, che mantiene i privilegi di amministratore, usa il
343 nome dell'utente per effettuare una ricerca nel database degli
344 utenti,\footnote{in genere viene chiamata \func{getpwnam}, che abbiamo visto
345 in \secref{sec:sys_user_group}, per leggere la password e gli altri dati dal
346 database degli utenti.} e richiede una password. Se l'utente non esiste o se
347 la password non corrisponde\footnote{il confronto non viene effettuato con un
348 valore in chiaro; quanto immesso da terminale viene invece a sua volta
349 criptato, ed è il risultato che viene confrontato con il valore che viene
350 mantenuto nel database degli utenti.} la richiesta viene ripetuta un certo
351 numero di volte dopo di che \cmd{login} esce ed \cmd{init} provvede a
352 rilanciare un'altra istanza di \func{getty}.
354 Se invece la password corrisponde \cmd{login} esegue \func{chdir} per settare
355 la \textit{home directory} dell'utente, cambia i diritti di accesso al
356 terminale (con \func{chown} e \func{chmod}) per assegnarne la titolarità
357 all'utente ed al suo gruppo principale, assegnandogli al contempo i diritti di
358 lettura e scrittura. Inoltre il programma provvede a costruire gli opportuni
359 valori per le variabili di ambiente, come \texttt{HOME}, \texttt{SHELL}, ecc.
360 Infine attraverso l'uso di \func{setuid}, \func{setpid} e \func{initgroups}
361 verrà cambiata l'identità del proprietario del processo, infatti, come
362 spiegato in \secref{sec:proc_setuid}, avendo invocato tali funzioni con i
363 privilegi di amministratore, tutti gli userid ed i groupid (reali, effettivi e
364 salvati) saranno settati a quelli dell'utente.
366 A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
367 iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
368 ad eseguire con un'altra \func{exec} la shell di login, che si troverà con un
369 ambiente già pronto e con file standard di \secref{sec:file_std_descr}
370 impostati sul terminale, pronta ad eseguire i comandi fino all'uscita. Dato
371 che il processo genitore resta sempre \cmd{init} quest'ultimo provvederà,
372 ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty}
373 per ripetere da capo tutto il procedimento.
377 \subsection{Prescrizioni per un programma \textit{daemon}}
378 \label{sec:sess_daemon}
380 Come sottolineato fin da \secref{sec:intro_base_concept}, in un sistema
381 unix-like tutte le operazioni sono eseguite tramite processi, comprese quelle
382 operazioni di sistema (come l'esecuzione di comandi periodici, o la consegna
383 della posta, ed in generale tutti i programmi di servizio) che non hanno a che
384 fare con la gestione diretta dei comandi dell'utente.
386 Questi programmi, che devono essere eseguiti in modalità non interattiva senza
387 nessun intervento dell'utente, sono normalmente chiamati \textsl{demoni}, (o
388 \textit{daemons}), nome ispirato dagli omonimi spiritelli che svolgevano vari
389 compiti, di cui parlava Socrate (che sosteneva di averne uno al suo
390 servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia sono
396 \section{L'I/O su terminale}
397 \label{sec:sess_terminal_io}
399 Esamineremo in questa sezione le peculiarità dell'I/O su terminale, tenendo
405 %%% TeX-master: "gapil"