1 \chapter{Terminali e sessioni di lavoro}
4 I terminali per lungo tempo tempo sono stati l'unico modo per accedere al
5 sistema, per questo anche oggi che esistono molte altre interfacce, essi
6 continuano a coprire un ruolo particolare, restando strettamente legati al
7 funzionamento dell'interfaccia a linea di comando.
9 Mella prima parte del capitolo esamineremo i concetti base del sistema delle
10 sessioni di lavoro, vale a dire il metodo con cui il kernel permette ad un
11 utente di gestire le capacità multitiasking del sistema, permettendo di
12 eseguire più programmi in contemporanea. Nella seconda parte del capitolo
13 tratteremo poi il funzionamento dell'I/O su terminale, e delle varie
14 peculiarità che esso viene ad assumere a causa del suo stretto legame con il
15 suo uso come interfaccia di accesso al sistema da parte degli utenti.
18 \section{Il \textit{job control}}
19 \label{sec:sess_job_control}
21 Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
22 il cui scopo è quello di permettere ad un utente di poter sfruttare le
23 capacità multitasking di un sistema Unix per eseguire in contemporanea più
24 processi, pur potendo accedere, di solito, ad un solo terminale,\footnote{con
25 X e con i terminali virtuali tutto questo non è più vero, dato che si può
26 accedere a molti terminali in contemporanea da una singola postazione di
27 lavoro, ma il sistema è nato prima dell'esistenza di tutto ciò.} avendo cioè
28 un solo punto in cui si può avere accesso all'input ed all'output degli
32 \subsection{Una panoramica introduttiva}
33 \label{sec:sess_job_control_overview}
35 Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
36 negli anni '80, e successivamente standardizzata da POSIX.1; la sua
37 disponibilità nel sistema è verificabile attraverso il controllo della macro
38 \macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
39 supporto sia da parte della shell (quasi tutte ormai lo fanno), che da parte
40 del kernel; in particolare il kernel deve assicurare sia la presenza di un
41 driver per i terminali abilitato al \textit{job control} che quella dei
42 relativi segnali illustrati in \secref{sec:sig_job_control}.
44 In un sistema che supporta il \textit{job control}, una volta completato il
45 login, l'utente avrà a disposizione una shell dalla quale eseguire i comandi e
46 potrà iniziare quella che viene chiamata una \textsl{sessione}, che riunisce
47 (vedi \secref{sec:sess_proc_group}) tutti i processi eseguiti all'interno
48 dello stesso login (esamineremo tutto il processo in dettaglio in
49 \secref{sec:sess_login}).
51 Siccome la shell è collegata ad un solo terminale, che viene usualmente
52 chiamato \textsl{terminale di controllo}, (vedi \secref{sec:sess_ctrl_term})
53 un solo comando alla volta (quello che viene detto in \textit{foreground}),
54 potrà scrivere e leggere dal terminale. La shell però può eseguire anche più
55 comandi in contemporanea, mandandoli in \textit{background} (aggiungendo una
56 \cmd{\&} alla fine del comando), nel qual caso essi saranno eseguiti senza
57 essere collegati al terminale.
59 Si noti come si sia parlato di comandi e non di programmi o processi; fra le
60 funzionalità della shell infatti c'è anche quella di consentire di concatenare
61 più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
62 eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
63 questo potrà sempre lanciare sottoprocessi per eseguire dei compiti specifici.
65 Per questo l'esecuzione di un comando può originare più di un processo; quindi
66 nella gestione del job control non si può far riferimento ai singoli processi.
67 Per questo il kernel prevede la possibilità di raggruppare più processi in un
68 \textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi
69 \secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
70 originano da una riga di comando appartengano allo stesso raggruppamento, in
71 modo che le varie funzioni di controllo, ed i segnali inviati dal terminale,
72 possano fare riferimento ad esso.
74 In generale allora all'interno di una sessione avremo un eventuale (può non
75 esserci) \textit{process group} in \textit{foreground}, che riunisce i
76 processi che possono accedere al terminale, e più \textit{process group} in
77 \textit{background}, che non possono accedervi. Il job control prevede che
78 quando un processo appartenente ad un raggruppamento in \textit{background}
79 cerca di accedere al terminale, venga inviato un segnale a tutti i processi
80 del raggruppamento, in modo da bloccarli (vedi \secref{sec:sess_ctrl_term}).
82 Un comportamento analogo si ha anche per i segnali generati dai comandi di
83 tastiera inviati dal terminale che vengono inviati a tutti i processi del
84 raggruppamento in \textit{foreground}. In particolare \cmd{C-z} interrompe
85 l'esecuzione del comando, che può poi essere mandato in \textit{background}
86 con il comando \cmd{bg}.\footnote{si tenga presente che \cmd{bg} e \cmd{fg}
87 sono parole chiave che indicano comandi interni alla shell, e nel caso non
88 comportano l'esecuzione di un programma esterno.} Il comando \cmd{fg}
89 consente invece di mettere in \textit{foreground} un comando precedentemente
90 lanciato in \textit{background}.
92 Di norma la shell si cura anche di notificare all'utente (di solito prima
93 della stampa a video del prompt) lo stato dei vari processi; essa infatti sarà
94 in grado, grazie all'uso di \func{waitpid}, di rilevare sia i processi che
95 sono terminati, sia i raggruppamenti che sono bloccati (in questo caso usando
96 l'opzione \macro{WUNTRACED}, secondo quanto illustrato in
97 \secref{sec:proc_wait}).
100 \subsection{I \textit{process group} e le \textsl{sessioni}}
101 \label{sec:sess_proc_group}
103 Come accennato in \secref{sec:sess_job_control_overview} nel job control i
104 processi vengono raggruppati in \textit{process group} e \textit{sessioni};
105 per far questo vengono utilizzati due ulteriori identificatori (oltre quelli
106 visti in \secref{sec:proc_pid}) che il kernel associa a ciascun
107 processo:\footnote{in Linux questi identificatori sono mantenuti nei campi
108 \var{pgrp} e \var{session} della struttura \var{task\_struct} definita in
109 \file{sched.h}.} l'identificatore del \textit{process group} e
110 l'identificatore della \textsl{sessione}, che vengono indicati rispettivamente
111 con le sigle \acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo
112 \type{pid\_t}. I valori di questi identificatori possono essere visualizzati
113 dal comando \cmd{ps} usando l'opzione \cmd{-j}.
115 Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
116 stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
117 le funzioni \func{getpgid} e \func{getpgrp},\footnote{\func{getpgrp} è
118 definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
119 i cui prototipi sono:
123 \funcdecl{pid\_t getpgid(pid\_t pid)}
124 Legge il \acr{pgid} del processo \param{pid}.
126 \funcdecl{pid\_t getpgrp(void)}
127 Legge il \acr{pgid} del processo corrente.
129 \bodydesc{Le funzioni restituiscono il \acr{pgid} del processo,
130 \func{getpgrp} ha sempre successo, mentre \func{getpgid} restituisce -1
131 ponendo \var{errno} a \macro{ESRCH} se il processo selezionato non esiste.}
134 La funzione \func{getpgid} permette di specificare il \acr{pid} del processo
135 di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
136 restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
137 equivalente a \code{getpgid(0)}.
139 In maniera analoga l'identificatore della sessione può essere letto dalla
140 funzione \func{getsid}, che però nelle \acr{glibc}\footnote{la system call è
141 stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
142 librerie del C è iniziato dalla versione 5.2.19. La funzione non è prevista
143 da POSIX.1, che parla solo di processi leader di sessione, e non di
144 identificatori di sessione.} è accessibile solo definendo
145 \macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}; il suo prototipo
147 \begin{prototype}{unistd.h}{pid\_t getsid(pid\_t pid)}
148 Legge l'identificatore di sessione del processo \param{pid}.
150 \bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
151 caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
154 \item[\macro{ESRCH}] Il processo selezionato non esiste.
155 \item[\macro{EPERM}] In alcune implementazioni viene restituito quando il
156 processo selezionato non fa parte della stessa sessione del processo
162 Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
163 processo con lo stesso valore che hanno nel processo padre, per cui un
164 processo appena creato appartiene sempre allo stesso raggruppamento e alla
165 stessa sessione del padre. Vedremo poi come sia possibile creare più
166 \textit{process group} all'interno della stessa sessione, e spostare i
167 processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
169 Ciascun raggruppamento di processi ha sempre un processo principale, il
170 cosiddetto \textit{process group leader}, che è identificato dall'avere un
171 \acr{pgid} uguale al suo \acr{pid}, in genere questo è il primo processo del
172 raggruppamento, che si incarica di lanciare tutti gli altri. Un nuovo
173 raggruppamento si crea con la funzione \func{setpgrp},\footnote{questa è la
174 definizione di POSIX.1, BSD definisce una funzione con lo stesso nome, che
175 però è identica a \func{setpgid}; nelle \acr{glibc} viene sempre usata
176 sempre questa definizione, a meno di non richiedere esplicitamente la
177 compatibilità all'indietro con BSD, definendo la macro
178 \macro{\_BSD\_SOURCE}.} il cui prototipo è:
179 \begin{prototype}{unistd.h}{int setpgrp(void)}
180 Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
182 \bodydesc{La funzione restituisce il valore del nuovo \textit{process
186 La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
187 corrente, rende questo \textit{group leader} di un nuovo raggruppamento, tutti
188 i successivi processi da esso creati apparterranno (a meno di non cambiare di
189 nuovo il \acr{pgid}) al nuovo raggruppamento. È possibile invece spostare un
190 processo da un raggruppamento ad un altro con la funzione \func{setpgid}, il
192 \begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
193 Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
195 \bodydesc{La funzione ritorna il valore del nuovo \textit{process group}, e
196 -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
198 \item[\macro{ESRCH}] Il processo selezionato non esiste.
199 \item[\macro{EPERM}] Il cambiamento non è consentito.
200 \item[\macro{EACCESS}] Il processo ha già eseguito una \func{exec}.
201 \item[\macro{EINVAL}] Il valore di \param{pgid} è negativo.
206 La funzione permette di cambiare il \acr{pgid} del processo \param{pid}, ma il
207 cambiamento può essere effettuato solo se \param{pgid} indica un
208 \textit{process group} che è nella stessa sessione del processo chiamante.
209 Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
210 dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha
211 ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
212 dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in
213 \var{task\_struct}.} Specificando un valore nullo per \param{pid} si indica
214 il processo corrente, mentre specificando un valore nullo per \param{pgid} si
215 imposta il \textit{process group} al valore del \acr{pid} del processo
216 selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0, 0)}.
218 Di norma questa funzione viene usata dalla shell quando si usano delle
219 pipeline, per mettere nello stesso process group tutti i programmi lanciati su
220 ogni linea di comando; essa viene chiamata dopo una \func{fork} sia dal
221 processo padre, per impostare il valore nel figlio, che da quest'ultimo, per
222 sé stesso, in modo che il cambiamento di \textit{process group} sia immediato
223 per entrambi; una delle due chiamate sarà ridondante, ma non potendo
224 determinare quale dei due processi viene eseguito per primo, occorre eseguirle
225 comunque entrambe per evitare di esporsi ad una race condition.
227 Si noti come nessuna delle funzioni esaminate finora permetta di spostare un
228 processo da una sessione ad un altra; infatti l'unico modo di far cambiare
229 sessione ad un processo è quello di crearne una nuova con l'uso di
230 \func{setsid}; il suo prototipo è:
231 \begin{prototype}{unistd.h}{pid\_t setsid(void)}
232 Crea una nuova sessione sul processo corrente impostandone \acr{sid} e
235 \bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di
236 errore, il solo errore possibile è \macro{EPERM}, che si ha quando il
237 \acr{pgid} e \acr{pid} del processo coincidono.}
240 La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
241 valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo
242 \textit{process group} di cui esso diventa leader (come per i \textit{process
243 group} un processo si dice leader di sessione\footnote{in Linux la proprietà
244 è mantenuta in maniera indipendente con un apposito campo \var{leader} in
245 \var{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed unico
246 componente. Inoltre la funzione distacca il processo da ogni terminale di
247 controllo (torneremo sull'argomento in \secref{sec:sess_ctrl_term}) cui fosse
248 in precedenza associato.
250 funzione ha successo soltanto se il processo non è già leader di un
251 \textit{process group}, per cui per usarla di norma si esegue una \func{fork}
252 e si esce, per poi chiamare \func{setsid} nel processo figlio, in modo che,
253 avendo questo lo stesso \acr{pgid} del padre ma un \acr{pid} diverso, non ci
254 siano possibilità di errore.\footnote{potrebbe sorgere il dubbio che, per il
255 riutilizzo dei valori dei \acr{pid} fatto nella creazione dei nuovi processi
256 (vedi \secref{sec:proc_pid}), il figlio venga ad assumere un valore
257 corrispondente ad un process group esistente; questo viene evitato dal
258 kernel che considera come disponibili per un nuovo \acr{pid} solo valori che
259 non corrispondono ad altri \acr{pid}, \acr{pgid} o \acr{sid} in uso nel
260 sistema.} Questa funzione viene usata di solito nel processo di login (per i
261 dettagli vedi \secref{sec:sess_login}) per raggruppare in una sessione tutti i
262 comandi eseguiti da un utente dalla sua shell.
266 \subsection{Il terminale di controllo e il controllo di sessione}
267 \label{sec:sess_ctrl_term}
269 Come accennato in \secref{sec:sess_job_control_overview}, nel sistema del
270 \textit{job control} i processi all'interno di una sessione fanno riferimento
271 ad un terminale di controllo (ad esempio quello su cui si è effettuato il
272 login), sul quale effettuano le operazioni di lettura e
273 scrittura,\footnote{nel caso di login grafico la cosa può essere più
274 complessa, e di norma l'I/O è effettuato tramite il server X, ma ad esempio
275 per i programmi, anche grafici, lanciati da un qualunque emulatore di
276 terminale, sarà quest'ultimo a fare da terminale (virtuale) di controllo.} e
277 dal quale ricevono gli eventuali segnali da tastiera.
279 A tale scopo lo standard POSIX.1 prevede che ad ogni sessione possa essere
280 associato un terminale di controllo; in Linux questo viene realizzato
281 mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
282 di controllo. \footnote{Lo standard POSIX.1 non specifica nulla riguardo
283 l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura
284 \var{task\_struct}, nel campo \var{tty}.} In generale ogni processo eredita
285 dal padre, insieme al \acr{pgid} e al \acr{sid} anche il terminale di
286 controllo (vedi \secref{sec:proc_fork}). In questo modo tutti processi
287 originati dallo stesso leader di sessione mantengono lo stesso terminale di
290 Alla creazione di una nuova sessione con \func{setsid} ogni associazione con
291 il precedente terminale di controllo viene cancellata, ed il processo che è
292 divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
293 è necessario, cosa che, come vedremo in \secref{sec:sess_daemon}, non è
294 sempre vera.}, un terminale di controllo. In generale questo viene fatto
295 automaticamente dal sistema\footnote{a meno di non avere richiesto
296 esplicitamente che questo non diventi un terminale di controllo con il flag
297 \macro{O\_NOCTTY} (vedi \secref{sec:file_open}). In questo Linux segue la
298 semantica di SVr4; BSD invece richiede che il terminale venga allocato
299 esplicitamente con una \func{ioctl} con il comando \macro{TIOCSCTTY}.}
300 quando viene aperto il primo terminale (cioè uno dei vari file di dispositivo
301 \file{/dev/tty*}) che diventa automaticamente il terminale di controllo,
302 mentre il processo diventa il \textsl{processo di controllo} di quella
305 In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
306 associato ai file standard (di input, output ed error) dei processi nella
307 sessione, ma solo quelli che fanno parte del cosiddetto raggruppamento di
308 \textit{foreground}, possono leggere e scrivere in certo istante. Per
309 impostare il raggruppamento di \textit{foreground} di un terminale si usa la
310 funzione \func{tcsetpgrp}, il cui prototipo è:
315 \funcdecl{int tcsetpgrp(int fd, pid\_t pgrpid)} Imposta a \param{pgrpid} il
316 \textit{process group} di \textit{foreground} del terminale associato al
317 file descriptor \param{fd}.
319 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
320 errore, nel qual caso \var{errno} assumerà i valori:
322 \item[\macro{ENOTTY}] Il file \param{fd} non corrisponde al terminale di
323 controllo del processo chiamante.
324 \item[\macro{ENOSYS}] Il sistema non supporta il job control.
325 \item[\macro{EPERM}] Il \textit{process group} specificato non è nella
326 stessa sessione del processo chiamante.
328 ed inoltre \macro{EBADF} ed \macro{EINVAL}.
331 \noindent la funzione può essere eseguita con successo solo da
332 un processo nella stessa sessione e con lo stesso terminale di controllo.
334 Come accennato in \secref{sec:sess_job_control_overview}, tutti i processi (e
335 relativi raggruppamenti) che non fanno parte del gruppo di \textit{foreground}
336 sono detti in \textit{background}; se uno si essi cerca di accedere al
337 terminale di controllo provocherà l'invio da parte del kernel di uno dei due
338 segnali \macro{SIGTTIN} o \macro{SIGTTOU} (a seconda che l'accesso sia stato
339 in lettura o scrittura) a tutto il suo \textit{process group}; dato che il
340 comportamento di default di questi segnali (si riveda quanto esposto in
341 \secref{sec:sig_job_control}) è di fermare il processo, di norma questo
342 comporta che tutti i membri del gruppo verranno fermati, ma non si avranno
343 condizioni di errore.\footnote{la shell in genere notifica comunque un
344 avvertimento, avvertendo la presenza di processi bloccati grazie all'uso di
345 \func{waitpid}.} Se però si bloccano o ignorano i due segnali citati, le
346 funzioni di lettura e scrittura falliranno con un errore di \macro{EIO}.
348 Un processo può controllare qual'è il gruppo di \textit{foreground} associato
349 ad un terminale con la funzione \func{tcgetpgrp}, il cui prototipo è:
351 \headdecl{unistd.h} \headdecl{termios.h}
353 \funcdecl{pid\_t tcgetpgrp(int fd)} Legge il \textit{process group} di
354 \textit{foreground} del terminale associato al file descriptor \param{fd}.
355 \bodydesc{La funzione restituisce in caso di successo il \acr{pgid} del
356 gruppo di \textit{foreground}, e -1 in caso di errore, nel qual caso
357 \var{errno} assumerà i valori:
359 \item[\macro{ENOTTY}] Non c'è un terminale di controllo o \param{fd} non
360 corrisponde al terminale di controllo del processo chiamante.
362 ed inoltre \macro{EBADF} ed \macro{ENOSYS}.
366 Si noti come entrambe le funzioni usino come argomento il valore di un file
367 descriptor, il risultato comunque non dipende dal file descriptor che si usa
368 ma solo dal terminale cui fa riferimento; il kernel inoltre permette a ciascun
369 processo di accedere direttamente al suo terminale di controllo attraverso il
370 file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il
371 proprio terminale di controllo. Questo consente anche a processi che possono
372 aver rediretto l'output di accedere al terminale di controllo, pur non
373 disponendo più del file descriptor originario; un caso tipico è il programma
374 \cmd{crypt} che accetta la redirezione sullo standard input di un file da
375 decifrare, ma deve poi leggere la password dal terminale.
377 Un'altra caratteristica del terminale di controllo usata nel job control è che
378 utilizzando su di esso le combinazioni di tasti speciali (\cmd{C-z},
379 \cmd{C-c}, \cmd{C-y} e \verb|C-\|) si farà sì che il kernel invii i
380 corrispondenti segnali (rispettivamente \macro{SIGTSTP}, \macro{SIGINT},
381 \macro{SIGQUIT} e \macro{SIGTERM}, trattati in \secref{sec:sig_job_control}) a
382 tutti i processi del raggruppamento di \textit{foreground}; in questo modo la
383 shell può gestire il blocco e l'interruzione dei vari comandi.
385 Per completare la trattazione delle caratteristiche del job control legate al
386 terminale di controllo, occorre prendere in considerazione i vari casi legati
387 alla terminazione anomala dei processi, che sono di norma gestite attraverso
388 il segnale \macro{SIGHUP}. Il nome del segnale deriva da \textit{hungup},
389 termine che viene usato per indicare la condizione in cui il terminale diventa
390 inutilizzabile, (letteralmente sarebbe \textsl{impiccagione}).
392 Quando si verifica questa condizione, ad esempio se si interrompe la linea, o
393 va giù la rete o più semplicemente si chiude forzatamente la finestra di
394 terminale su cui si stava lavorando, il kernel provvederà ad inviare il
395 segnale di \macro{SIGHUP} al processo di controllo. L'azione preimpostata in
396 questo caso è la terminazione del processo, il problema che si pone è cosa
397 accade agli altri processi nella sessione, che non han più un processo di
398 controllo che possa gestire l'accesso al terminale, che potrebbe essere
399 riutilizzato per qualche altra sessione.
401 Lo standard POSIX.1 prevede che quando il processo di controllo termina, che
402 ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si
403 potrebbe terminare direttamente la shell con \cmd{kill}) venga inviato un
404 segnale di \macro{SIGHUP} ai processi del raggruppamento di foreground. In
405 questo modo essi potranno essere avvisati che non esiste più un processo in
406 grado di gestire il terminale (di norma tutto ciò comporta la terminazione
407 anche di questi ultimi).
409 Restano però gli eventuali processi in background, che non ricevono il
410 segnale; in effetti se il terminale non dovesse più servire essi potrebbero
411 proseguire fino al completamento della loro esecuzione; ma si pone il problema
412 di come gestire quelli che sono bloccati, o che si bloccano nell'accesso al
413 terminale, in assenza di un processo che sia in grado di effettuare il
414 controllo dello stesso.
416 Questa è la situazione in cui si ha quello che viene chiamato un
417 \textit{orphaned process group}. Lo standard POSIX.1 lo definisce come un
418 \textit{process group} i cui processi hanno come padri esclusivamente o altri
419 processi nel raggruppamento, o processi fuori della sessione. Lo standard
420 prevede inoltre che se la terminazione di un processo fa sì che un
421 raggruppamento di processi diventi orfano e se i suoi membri sono bloccati, ad
422 essi vengano inviati in sequenza i segnali di \macro{SIGHUP} e
425 La definizione può sembrare complicata, e a prima vista non è chiaro cosa
426 tutto ciò abbia a che fare con il problema della terminazione del processo di
427 controllo. Consideriamo allora cosa avviene di norma nel \textit{job
428 control}: una sessione viene creata con \func{setsid} che crea anche un
429 nuovo process group: per definizione quest'ultimo è sempre \textsl{orfano},
430 dato che il padre del leader di sessione è fuori dalla stessa e il nuovo
431 process group contiene solo il leader di sessione. Questo è un caso limite, e
432 non viene emesso nessun segnale perché quanto previsto dallo standard riguarda
433 solo i raggruppamenti che diventano orfani in seguito alla terminazione di un
434 processo.\footnote{l'emissione dei segnali infatti avviene solo nella fase di
435 uscita del processo, come una delle operazioni legate all'esecuzione di
436 \func{\_exit}, secondo quanto illustrato in \secref{sec:proc_termination}.}
438 Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
439 punto non sono orfani in quanto esso resta padre per almeno uno dei processi
440 del gruppo (gli altri possono derivare dal primo). Alla terminazione del
441 leader di sessione però avremo che, come visto in
442 \secref{sec:proc_termination}, tutti i suoi figli vengono adottati da
443 \cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process
444 group creati direttamente dal leader di sessione (a meno di non aver spostato
445 con \func{setpgid} un processo da un gruppo ad un altro, cosa che di norma non
446 viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali;
447 \macro{SIGCONT} ne farà proseguire l'esecuzione, ed essendo stato nel
448 frattempo inviato anche \macro{SIGHUP}, se non c'è un gestore per
449 quest'ultimo, i processi bloccati verranno automaticamente terminati.
453 \subsection{Dal login alla shell}
454 \label{sec:sess_login}
456 L'organizzazione del sistema del job control è strettamente connessa alle
457 modalità con cui un utente accede al sistema per dare comandi, collegandosi ad
458 esso con un terminale, che sia questo realmente tale, come un VT100 collegato
459 ad una seriale o virtuale, come quelli associati a schermo e tastiera o ad una
460 connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
461 fine le differenze sono\footnote{in generale nel caso di login via rete o di
462 terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
463 ha origine l'esecuzione della shell.} nel dispositivo cui il kernel associa i
464 file standard (vedi \secref{sec:file_std_descr}) per l'I/O, tratteremo solo il
465 caso classico del terminale.
467 Abbiamo già brevemente illustrato in \secref{sec:intro_kern_and_sys} le
468 modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
469 vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
470 dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
471 shell che gli permette di lanciare i suoi comandi su un terminale.
473 Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
474 distribuzione \textit{Slackware}, come alcune distribuzioni su dischetto, ed
475 altre distribuzioni dedicate a compiti limitati e specifici.} viene usata
476 la procedura di avvio di System V; questa prevede che \cmd{init} legga dal
477 file di configurazione \file{/etc/inittab} quali programmi devono essere
478 lanciati, ed in quali modalità, a seconda del cosiddetto \textit{run level},
479 anch'esso definito nello stesso file.
481 Tralasciando la descrizione del sistema dei run level, (per il quale si
482 rimanda alla lettura delle pagine di manuale di \cmd{init} e di
483 \file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno
484 una istanza di un programma che permetta l'accesso ad un terminale. Uno schema
485 di massima della procedura è riportato in \figref{fig:sess_term_login}.
489 \includegraphics[width=15cm]{img/tty_login}
490 \caption{Schema della procedura di login su un terminale.}
491 \label{fig:sess_term_login}
494 Un terminale, che esso sia un terminale effettivo, attaccato ad una seriale o
495 ad un altro tipo di porta di comunicazione, o una delle console virtuali
496 associate allo schermo, viene sempre visto attraverso attraverso un device
497 driver che ne presenta un'interfaccia comune su un apposito file di
500 Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
501 delle sue varianti), che permette di mettersi in ascolto su uno di questi
502 dispositivi. Alla radice della catena che porta ad una shell per i comandi
503 perciò c'è sempre \cmd{init} che esegue prima una \func{fork} e poi una
504 \func{exec} per lanciare una istanza di questo programma su un terminale, il
505 tutto ripetuto per ciascuno dei terminali che si hanno a disposizione (o per
506 un certo numero di essi, nel caso delle console virtuali), secondo quanto
507 indicato dall'amministratore nel file di configurazione del programma,
510 Quando viene lanciato da \cmd{init} il programma parte con i privilegi di
511 amministratore e con un ambiente vuoto; \cmd{getty} si cura di chiamare
512 \func{setsid} per creare una nuova sessione ed un nuovo process group, e di
513 aprire il terminale (che così diventa il terminale di controllo della
514 sessione) in lettura sullo standard input ed in scrittura sullo standard
515 output e sullo standard error; inoltre effettuerà, qualora servano, ulteriori
516 settaggi.\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
517 di login in maiuscolo, può effettuare la conversione automatica dell'input
518 in minuscolo, ponendosi in una modalità speciale che non distingue fra i due
519 tipi di caratteri (a beneficio di alcuni vecchi terminali che non
520 supportavano le minuscole).} Alla fine il programma stamperà un messaggio di
521 benvenuto per poi porsi in attesa dell'immissione del nome di un utente.
523 Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
524 il programma \cmd{login} con una \func{exevle}, passando come argomento la
525 stringa con il nome, ed un ambiente opportunamente costruito che contenga
526 quanto necessario (ad esempio di solito viene opportunamente inizializzata la
527 variabile di ambiente \texttt{TERM}) ad identificare il terminale su cui si
528 sta operando, a beneficio dei programmi che verranno lanciati in seguito.
530 A sua volta \cmd{login}, che mantiene i privilegi di amministratore, usa il
531 nome dell'utente per effettuare una ricerca nel database degli
532 utenti,\footnote{in genere viene chiamata \func{getpwnam}, che abbiamo visto
533 in \secref{sec:sys_user_group}, per leggere la password e gli altri dati dal
534 database degli utenti.} e richiede una password. Se l'utente non esiste o se
535 la password non corrisponde\footnote{il confronto non viene effettuato con un
536 valore in chiaro; quanto immesso da terminale viene invece a sua volta
537 criptato, ed è il risultato che viene confrontato con il valore che viene
538 mantenuto nel database degli utenti.} la richiesta viene ripetuta un certo
539 numero di volte dopo di che \cmd{login} esce ed \cmd{init} provvede a
540 rilanciare un'altra istanza di \func{getty}.
542 Se invece la password corrisponde \cmd{login} esegue \func{chdir} per settare
543 la \textit{home directory} dell'utente, cambia i diritti di accesso al
544 terminale (con \func{chown} e \func{chmod}) per assegnarne la titolarità
545 all'utente ed al suo gruppo principale, assegnandogli al contempo i diritti di
546 lettura e scrittura. Inoltre il programma provvede a costruire gli opportuni
547 valori per le variabili di ambiente, come \texttt{HOME}, \texttt{SHELL}, ecc.
548 Infine attraverso l'uso di \func{setuid}, \func{setpid} e \func{initgroups}
549 verrà cambiata l'identità del proprietario del processo, infatti, come
550 spiegato in \secref{sec:proc_setuid}, avendo invocato tali funzioni con i
551 privilegi di amministratore, tutti gli userid ed i groupid (reali, effettivi e
552 salvati) saranno settati a quelli dell'utente.
554 A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
555 iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
556 ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
557 già pronto con i file standard di \secref{sec:file_std_descr} impostati sul
558 terminale, e pronta, nel ruolo di leader di sessione e di processo di
559 controllo per il terminale, a gestire l'esecuzione dei comandi come illustrato
560 in \secref{sec:sess_job_control_overview}.
562 Dato che il processo padre resta sempre \cmd{init} quest'ultimo potrà
563 provvedere, ricevendo un \macro{SIGCHLD} all'uscita della shell quando la
564 sessione di lavoro è terminata, a rilanciare \cmd{getty} sul terminale per
565 ripetere da capo tutto il procedimento.
569 \subsection{Prescrizioni per un programma \textit{daemon}}
570 \label{sec:sess_daemon}
572 Come sottolineato fin da \secref{sec:intro_base_concept}, in un sistema
573 unix-like tutte le operazioni sono eseguite tramite processi, comprese quelle
574 operazioni di sistema (come l'esecuzione dei comandi periodici, o la consegna
575 della posta, ed in generale tutti i programmi di servizio) che non hanno
576 niente a che fare con la gestione diretta dei comandi dell'utente.
578 Questi programmi, che devono essere eseguiti in modalità non interattiva e
579 senza nessun intervento dell'utente, sono normalmente chiamati
580 \textsl{demoni}, (o \textit{daemons}), nome ispirato dagli omonimi spiritelli
581 che svolgevano compiti vari, di cui parlava Socrate (che sosteneva di averne
582 uno al suo servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia
583 sono piuttosto datati.}
585 Se però si lancia un programma demone dalla riga di comando in un sistema che
586 supporta, come Linux, il \textit{job control} esso verrà comunque associato ad
587 un terminale di controllo e mantenuto all'interno di una sessione, e anche se
588 può essere mandato in background e non eseguire più nessun I/O su terminale,
589 si avranno comunque tutte le conseguenze che abbiamo appena visto in
590 \secref{sec:sess_ctrl_term} (in particolare l'invio dei segnali in
591 corrispondenza dell'uscita del leader di sessione).
593 Per questo motivo un programma che deve funzionare come demone deve sempre
594 prendere autonomamente i provvedimenti opportuni (come distaccarsi dal
595 terminale e dalla sessione) ad impedire eventuali interferenze da parte del
596 sistema del \textit{job contol}; questi sono riassunti in una lista di
597 prescrizioni\footnote{ad esempio sia Stevens in \cite{APUE}, che la
598 \textit{Unix Programming FAQ} \cite{UnixFAQ} ne riportano di sostanzialmente
599 identiche.} da seguire quando si scrive un demone.
601 Pertanto, quando si lancia un programma che deve essere eseguito come demone
602 occorrerà predisporlo in modo che esso compia le seguenti azioni:
604 \item Eseguire una \func{fork} e terminare immediatamente il processo padre
605 proseguendo l'esecuzione nel figlio. In questo modo si ha la certezza che
606 il figlio non è un \textit{process group leader}, (avrà il \acr{pgid} del
607 padre, ma un \acr{pid} diverso) e si può chiamare \func{setsid} con
608 successo. Inoltre la shell considererà terminato il comando all'uscita del
610 \item Eseguire \func{setsid} per creare una nuova sessione ed un nuovo
611 raggruppamento di cui il processo diventa automaticamente il leader, che
612 però non ha associato nessun terminale di controllo.
613 \item Assicurarsi che al processo non venga associato in seguito nessun nuovo
614 terminale di controllo; questo può essere fatto sia avendo cura di usare
615 sempre l'opzione \macro{O\_NOCTTY} nell'aprire i file di terminale, che
616 eseguendo una ulteriore \func{fork} uscendo nel padre e proseguendo nel
617 figlio. In questo caso, non essendo più quest'ultimo un leader di sessione
618 non potrà ottenere automaticamente un terminale di controllo.
619 \item Eseguire una \func{chdir} per impostare la directory di lavoro del
620 processo (su \file{/} o su una directory che contenga dei file necessari per
621 il programma), per evitare che la directory da cui si è lanciato il processo
622 resti in uso e non sia possibile rimuoverla o smontare il filesystem che la
624 \item Impostare la maschera dei permessi (di solito con \code{umask(0)}) in
625 modo da non essere dipendenti dal valore ereditato da chi ha lanciato
626 originariamente il processo.
627 \item Chiudere tutti i file aperti che non servono più (in generale tutti); in
628 particolare vanno chiusi i file standard che di norma sono ancora associati
629 al terminale (un'altra opzione è quella di redirigerli verso
634 In Linux buona parte di queste azioni possono venire eseguite invocando la
635 funzione \func{daemon}, introdotta per la prima volta in BSD4.4; il suo
637 \begin{prototype}{unistd.h}{int daemon(int nochdir, int noclose)}
638 Esegue le operazioni che distaccano il processo dal terminale di controllo e
639 lo fanno girare come demone.
641 \bodydesc{La funzione restituisce (nel nuovo processo) 0 in caso di
642 successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
643 valori impostati dalle sottostanti \func{fork} e \func{setsid}.}
646 La funzione esegue una \func{fork}, per uscire subito, con \func{\_exit}, nel
647 padre, mentre l'esecuzione prosegue nel figlio che esegue subito una
648 \func{setsid}. In questo modo si compiono automaticamente i passi 1 e 2 della
649 precedente lista. Se \param{nochdir} è nullo la funzione imposta anche la
650 directory di lavoro su \file{/}, se \param{noclose} è nullo i file standard
651 vengono rediretti su \file{/dev/null} (corrispondenti ai passi 4 e 6); in caso
652 di valori non nulli non viene eseguita nessuna altra azione.
654 Dato che un programma demone non può più accedere al terminale, si pone il
655 problema di come fare per la notifica di eventuali errori, non potendosi più
656 utilizzare lo standard error; per il normale I/O infatti ciascun demone avrà
657 le sue modalità di interazione col sistema e gli utenti a seconda dei compiti
658 e delle funzionalità che sono sono previste; ma gli errori devono normalmente
659 essere notificati all'amministratore del sistema.
661 Una soluzione può essere quella di scrivere gli eventuali messaggi su uno
662 specifico file (cosa che a volte viene fatta comunque) ma questo comporta il
663 grande svantaggio che l'amministratore dovrà tenere sotto controllo un file
664 diverso per ciascun demone, e che possono anche generarsi conflitti di nomi.
665 Per questo in BSD4.2 venne introdotto un servizio di sistema, il
666 \textit{syslog}, che oggi si trova su tutti i sistemi Unix, e che permettesse
667 ai demoni di inviare messaggi all'amministratore in una maniera
670 Il servizio prevede vari meccanismi di notifica, e, come ogni altro servizio
671 in un sistema unix-like, viene gestito attraverso un apposito programma,
672 \cmd{syslogd}, che è anch'esso un \textsl{demone}. In generale i messaggi di
673 errore vengono raccolti dal file speciale \file{/dev/log}, un \textit{socket}
674 locale (vedi \secref{sec:sock_sa_local}) dedicato a questo scopo, o via rete,
675 con un \textit{socket} UDP, o da un apposito demone, \cmd{klogd}, che estrae i
676 messaggi del kernel.\footnote{i messaggi del kernel sono tenuti in un buffer
677 circolare e scritti tramite la funzione \func{printk}, analoga alla
678 \func{printf} usata in user space; una trattazione eccellente dell'argomento
679 si trova in \cite{LinDevDri}, nel quarto capitolo.}
681 Il servizio permette poi di trattare i vari messaggi classificandoli
682 attraverso due indici; il primo, chiamato \textit{facility}, suddivide in
683 diverse categorie i vari demoni in modo di raggruppare i messaggi provenienti
684 da operazioni che hanno attinenza fra loro, ed è organizzato in sottosistemi
685 (kernel, posta elettronica, demoni di stampa, ecc.). Il secondo, chiamato
686 \textit{priority}, identifica l'importanza dei vari messaggi, e permette di
687 classificarli e differenziare le modalità di notifica degli stessi.
689 Il sistema di \textit{syslog} attraverso \cmd{syslogd} provvede poi a
690 riportare i messaggi all'amministratore attraverso una serie differenti
693 \item scrivere sulla console.
694 \item inviare via mail ad uno specifico utente.
695 \item scrivere su un file (comunemente detto \textit{log file}).
696 \item inviare ad un altro demone (anche via rete).
699 secondo le modalità che questo preferisce e che possono essere impostate
700 attraverso il file di configurazione \file{/etc/syslog.conf} (maggiori
701 dettagli si possono trovare sulle pagine di manuale per questo file e per
704 Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
705 può accedere in maniera generica al servizio di \textit{syslog}, che però
706 funzionano solo localmente; se si vogliono inviare i messaggi ad un'altro
707 sistema occorre farlo esplicitamente con un socket UDP, o utilizzare le
708 capacità di reinvio del servizio.
710 La prima funzione definita dall'interfaccia è \func{openlog}, che apre una
711 connessione al servizio di \textit{syslog}; essa in generale non è necessaria
712 per l'uso del servizio, ma permette di impostare alcuni valori che controllano
713 gli effetti delle chiamate successive; il suo prototipo è:
714 \begin{prototype}{syslog.h}{void openlog(const char *ident, int option,
717 Apre una connessione al sistema di \textit{syslog}.
719 \bodydesc{La funzione non restituisce nulla.}
722 La funzione permette di specificare, tramite \param{ident}, l'identità di chi
723 ha inviato il messaggio (di norma si passa il nome del programma, come
724 specificato da \code{argv[0]}); la stringa verrà preposta all'inizio di ogni
725 messaggio. Si tenga presente che il valore di \param{ident} che si passa alla
726 funzione è un puntatore, se la stringa cui punta viene cambiata lo sarà pure
727 nei successivi messaggi, e se viene cancellata i risultati potranno essere
728 impredicibili, per questo è sempre opportuno usare una stringa costante.
730 L'argomento \param{facility} permette invece di preimpostare per le successive
731 chiamate l'omonimo indice che classifica la categoria del messaggio.
732 L'argomento è interpretato come una maschera binaria, e pertanto è possibile
733 inviare i messaggi su più categorie alla volta; i valori delle costanti che
734 identificano ciascuna categoria sono riportati in
735 \tabref{tab:sess_syslog_facility}, il valore di \param{facility} deve essere
736 specificato con un OR aritmetico.
741 \begin{tabular}[c]{|l|p{8cm}|}
743 \textbf{Valore}& \textbf{Significato}\\
746 \macro{LOG\_AUTH} & Messaggi relativi ad autenticazione e sicurezza,
747 obsoleto, è sostituito da \macro{LOG\_AUTHPRIV}. \\
748 \macro{LOG\_AUTHPRIV} & Sostituisce \macro{LOG\_AUTH}.\\
749 \macro{LOG\_CRON} & Messaggi dei demoni di gestione dei comandi
750 programmati (\cmd{cron} e \cmd{at}).\\
751 \macro{LOG\_DAEMON} & Demoni di sistema.\\
752 \macro{LOG\_FTP} & Server FTP.\\
753 \macro{LOG\_KERN} & Messaggi del kernel\\
754 \macro{LOG\_LOCAL0} & Riservato all'amministratore per uso locale\\
756 \macro{LOG\_LOCAL7} & Riservato all'amministratore per uso locale\\
757 \macro{LOG\_LPR} & Messaggi del sistema di gestione delle stampanti \\
758 \macro{LOG\_MAIL} & Messaggi del sistema di posta elettronica\\
759 \macro{LOG\_NEWS} & Messaggi del sistema di gestione delle news
761 \macro{LOG\_SYSLOG} & Messaggi generati dallo stesso \cmd{syslogd}\\
762 \macro{LOG\_USER} & Messaggi generici a livello utente\\
763 \macro{LOG\_UUCP} & Messaggi del sistema UUCP\\
766 \caption{Valori possibili per l'argomento \param{facility} di \func{openlog}.}
767 \label{tab:sess_syslog_facility}
770 L'argomento \param{option} serve invece per controllare il comportamento della
771 funzione \func{openlog} e delle modalità con cui le successive chiamate
772 scriveranno i messaggi, esso viene specificato come maschera binaria composta
773 con un OR aritmetico di una qualunque delle costanti riportate in
774 \tabref{tab:sess_openlog_option}.
779 \begin{tabular}[c]{|l|p{8cm}|}
781 \textbf{Valore}& \textbf{Significato}\\
784 \macro{LOG\_CONS} & Scrive sulla console quando. \\
785 \macro{LOG\_NDELAY} & Sostituisce \macro{LOG\_AUTH}.\\
786 \macro{LOG\_NOWAIT} & Messaggi dei demoni di gestione dei comandi
787 programmati (\cmd{cron} e \cmd{at}).\\
788 \macro{LOG\_ODELAY} & .\\
789 \macro{LOG\_PERROR} & Stampa anche su \file{stderr}.\\
790 \macro{LOG\_PID} & Inserisce nei messaggi il \acr{pid} del processo
794 \caption{Valori possibili per l'argomento \param{option} di \func{openlog}.}
795 \label{tab:sess_openlog_option}
798 La funzione che si usa per generare un messaggio è \func{syslog}, dato che
799 l'uso di \func{openlog} è ozionale, sarà quest'ultima a provvede a chiamare la
800 prima qualora ciò non sia stato fatto (nel qual caso il valore di
801 \param{ident} è nullo). Il suo prototipo è:
802 \begin{prototype}{syslog.h}
803 {void syslog(int priority, const char *format, ...)}
805 Genera un messaggio di priorità \param{priority}.
807 \bodydesc{La funzione non restituisce nulla.}
810 Il comportamento della funzione è analogo quello di \func{printf}, e il valore
811 dell'argomento \param{format} è identico a quello descritto nella pagina di
812 manuale di quest'ultima (per i valori principali si può vedere la trattazione
813 sommaria che se ne è fatto in \secref{sec:file_formatted_io}); l'unica
814 differenza è che la sequenza \cmd{\%m} viene rimpiazzata dalla stringa
815 restituita da \code{strerror(errno)}. Gli argomenti seguenti i primi due
816 devono essere forniti secondo quanto richiesto da \func{format}.
818 L'argomento \param{priority} permette di impostare sia la \textit{facility}
819 che la \textit{priority} del messaggio. In realtà viene prevalentemente usato
820 per specificare solo quest'ultima in quanto la prima viene di norma
821 preimpostata con \func{openlog}. La priorità è indicata con un valore
822 numerico\footnote{le \acr{glibc}, seguendo POSIX.1-2001, prevedono otto
823 diverse priorità ordinate da 0 a 7, in ordine di importanza decrescente;
824 questo comporta che i tre bit meno significativi dell'argomento
825 \param{priority} sono occupati da questo valore, mentre i restanti bit più
826 significativi vengono usati per specificare la \textit{facility}.}
827 specificabile attraverso le costanti riportate in
828 \secref{tab:sess_syslog_priority}. Nel caso si voglia specificare anche la
829 \textit{facility} basta eseguire un OR aritmetico del valore della priorità
830 con la maschera binaria delle costanti di \tabref{tab:sess_syslog_facility}.
835 \begin{tabular}[c]{|l|p{8cm}|}
837 \textbf{Valore}& \textbf{Significato}\\
840 \macro{LOG\_EMERG} & Il sistema è inutilizzabile. \\
841 \macro{LOG\_ALERT} & C'è una emergenza che richiede intervento
843 \macro{LOG\_CRIT} & Si è in una condizione critica.\\
844 \macro{LOG\_ERR} & Si è in una condizione di errore.\\
845 \macro{LOG\_WARNING} & Messaggio di avvertimento.\\
846 \macro{LOG\_NOTICE} & Notizia significativa relativa al comportamento.\\
847 \macro{LOG\_INFO} & Messaggio informativo. \\
848 \macro{LOG\_DEBUG} & Messaggio di debug.\\
851 \caption{Valori possibili per l'indice di importanza del messaggio da
852 specificare nell'argomento \param{priority} di \func{syslog}.}
853 \label{tab:sess_syslog_priority}
856 Una ulteriore funzione, \func{setlogmask}, permette di filtrare
857 preliminarmente i messaggi in base alla loro priorità; il suo prototipo è:
858 \begin{prototype}{syslog.h}
859 {int setlogmask(int mask)}
861 Imposta la maschera dei log al valore specificato.
863 \bodydesc{La funzione restituisce il precedente valore.}
866 Le routine di gestione mantengono per ogni processo una maschera che
867 determina quale delle chiamate effettuate a \func{syslog} verrà
868 effettivamente registrata. La registrazione viene disabilitata per tutte
869 quelle priorità che non rientrano nella maschera; questa viene settata
870 usando la macro \code{LOG\_MASK(p)} dove \code{p} è una delle costanti di
871 \secref{tab:sess_syslog_priority}. É inoltre disponibile anche la macro
872 \code{LOG\_UPTO(p)} che permette di specificare automaticamente tutte le
873 priorità fino ad un certo valore.
877 \section{L'I/O su terminale}
878 \label{sec:sess_terminal_io}
880 Benché come ogni altro dispositivo i terminali siano accessibili come file,
881 essi hanno assunto storicamente (essendo stati a lungo l'unico modo di
882 accedere al sistema) una loro rilevanza specifica, che abbiamo già avuto modo
883 di incontrare nella precedente sezione.
885 Esamineremo qui le peculiarità dell'I/O eseguito sui terminali, che per la
886 loro particolare natura presenta delle differenze rispetto ai normali file su
887 disco e agli altri dispositivi.
891 \subsection{L'architettura}
892 \label{sec:term_design}
895 I terminali sono una classe speciale di dispositivi a caratteri (si rammenti
896 la classificazione di \secref{sec:file_file_types}); un terminale ha infatti
897 una caratteristica che lo contraddistingue da un qualunque altro dispositivo,
898 e cioè che è destinato a gestire l'interazione con un utente (deve essere in
899 grado di fare da terminale di controllo per una sessione), che comportano la
900 presenza di ulteriori capacità.
902 L'interfaccia per i terminali è una delle più oscure e complesse, essendosi
903 stratificata dagli inizi dei sistemi Unix fino ad oggi. Questo comporta una
904 grande quantità di opzioni e controlli relativi ad un insieme di
905 caratteristiche (come ad esempio la velocità della linea) necessarie per
906 dispositivi, come i terminali seriali, che al giorno d'oggi sono praticamente
909 Storicamente i primi terminali erano appunto terminali di telescriventi
910 (\textit{teletype}), da cui deriva sia il nome dell'interfaccia, \textit{TTY},
911 che quello dei relativi file di dispositivo, che sono sempre della forma
912 \texttt{/dev/tty*}.\footnote{ciò vale solo in parte per i terminali virtuali,
913 essi infatti hanno due lati, un \textit{master}, che può assumere i nomi
914 \file{/dev/pty[p-za-e][0-9a-f]} ed un corrispondente \textit{slave} con nome
915 \file{/dev/tty[p-za-e][0-9a-f]}.} Oggi essi includono le porte seriali, le
916 console virtuali dello schermo, i terminali virtuali che vengono creati come
917 canali di comunicazione dal kernel e che di solito vengono associati alle
918 connessioni di rete (ad esempio per trattare i dati inviati con \cmd{telnet} o
921 % In generale tutti i terminali hanno un insieme di funzionalità comuni, che
922 % vengono chiamate \textsl{discipline di linea}; esse contraddistinguono le
923 % modalità con cui il kernel manipola (ad esempio la reazione ad un carattere di
924 % cancellazione per la tastiera, o la gestione della linea tramite PPP o SLIP) i
925 % dati grezzi che vengono immessi sul dispositivo;
928 L'I/O sui terminali si effettua con le stesse modalità dei file normali, si
929 apre il relativo file di dispositivo, e si leggono e scriveno i dati con le
930 usuali funzioni di lettura e scrittura, occorre però tenere conto delle loro
931 caratteristiche specifiche, essi infatti prevedono due modalità di operazione,
932 dette rispettivamente \textsl{modo canonico} e \textsl{modo non canonico}, che
933 prevedono dei comportamenti nettamente diversi.
935 La modalità preimpostata all'apertura del terminale è quella canonica, in cui
936 le operazioni di lettura vengono sempre effettuate assemblando i dati in una
937 linea;\footnote{per cui eseguendo una \func{read} su un terminale in modo
938 canonico la funzione si bloccherà, anche se si sono scritti dei caratteri,
939 fintanto che non si preme il tasto di ritorno a capo: a questo punto la
940 linea sarà completa e la funzione ritornerà.} ed in cui alcuni caratteri
941 vengono interpretati per compiere operazioni (come la generazione dei segnali
942 illustrati in \secref{sec:sig_job_control}), questa di norma è la modalità in
943 cui funziona la shell.
945 Un terminale in modo non canonico invece non effettua nessun accorpamento dei
946 dati in linee né li interpreta; esso viene di solito usato dai programmi (gli
947 editor ad esempio) che necessitano di poter leggere un carattere alla volta e
948 che gestiscono al loro interno i vari comandi.
950 La struttura dell'I/O, come di solito viene gestito dal driver del terminale è
951 mostrata in \secref{fig:term_struct}
955 \includegraphics[width=13cm]{img/term_struct}
956 \caption{Struttura interna generica di un driver per un terminale.}
957 \label{fig:term_struct}
961 L'I/O viene controllato attraverso una serie di attributi mantenuti per
962 ciascun terminale in una struttura \var{termios}, i cui campi
967 \footnotesize \centering
968 \begin{minipage}[c]{15cm}
969 \begin{lstlisting}[labelstep=0]{}
971 tcflag_t c_iflag; /* input modes */
972 tcflag_t c_oflag; /* output modes */
973 tcflag_t c_cflag; /* control modes */
974 tcflag_t c_lflag; /* local modes */
975 cc_t c_cc[NCCS]; /* control chars */
980 \caption{La struttura \var{termios}, che identifica le proprietà di un
982 \label{fig:term_termios}
987 \subsection{Il \textsl{modo canonico}}
988 \label{sec:term_canonic_mode}
993 \subsection{Il \textsl{modo non canonico}}
994 \label{sec:term_noncanonic_mode}
1001 %%% Local Variables:
1003 %%% TeX-master: "gapil"