risistemato il capitolo sulle sessioni di lavoro

diff --git a/session.tex b/session.tex
index d3a0e4febe57d617587780caa081c02688c04bb7..cdc557360e7171ba87bed6c0715662f15134bfd9 100644 (file)
--- a/session.tex
+++ b/session.tex
@@ -1,39 +1,105 @@
 \chapter{Sessioni di lavoro}
 \label{cha:session}
 
 \chapter{Sessioni di lavoro}
 \label{cha:session}
 

-Esamineremo in questo capitolo le modalità in cui sono organizzati i processi
-all'interno del sistema e le varie relazioni che intercorrono fra di essi, e
-le modalità che permettono, a partire dall'avvio del sistema, di organizzare
-il lavoro degli utenti in sessioni di lavoro associate ai terminali di
-controllo con cui essi si sono collegati al sistema.
+Unix nasce prima dell'esistenza dei moderni PC, quando i computer occupavano
+stanze intere e ci si poteva collegare solo attraverso dei terminali, ma fin
+dalle sue origini è sempre stato un sistema multitasking e multiutente,
+in grado di consentire l'utilizzo di un solo computer da parte di più persone.

 
 

-\section{La procedura di login}
+Esamineremo in questo capitolo i concetti base del sistema delle sessioni di
+lavoro, vale a dire il metodo con cui il kernel gestisce l'accesso concorrente
+al sistema da parte di più utenti, permettendo loro di eseguire più programmi
+in contemporanea.
+
+
+\section{Il \textit{Job control}}
+\label{sec:sess_job_control}
+
+Viene comunemente chiamato \textit{Job control} quell'insieme di funzionalità
+del sistema il cui scopo è quello di permettere ad un utente di poter
+sfruttare le capacità multitasking di un sistema Unix per eseguire in
+contemporanea più processi, pur potendo accedere, di solito, ad un solo
+terminale,\footnote{con X e con i terminali vituali tutto questo non è più
+  vero, dato che si può accedere a molti terminali in contemporanea, ma il
+  sistema è nato prima dell'esistenza di tutto ciò.} avendo cioè un solo punto
+in cui si può avere accesso all'input ed all'output degli stessi.
+
+
+\subsection{La struttura di base}
+\label{sec:sess_relation}
+
+Per poter gestire il \textit{Job Control} il kernel associa a ciascun processo
+due ulteriori identificatori (oltre quelli visti in \secref{sec:proc_pid}):
+l'identificatore del cosiddetto \textit{process group} (o
+\textsl{ragguppamento di processi}), cui si fa di norma riferimento con la
+sigla \acr{pgid}, l'identificatore di sessione (il \textit{session id}) cui si
+fa riferimento con la sigla \acr{sid}).  In questo modo, sulla base dei valori
+dei rispettivi indicatori, i processi vengono organizzati in \textsl{sessioni}
+e \textsl{raggruppamenti}.
+
+Entrambi gli identificatori vengono impostati alla creazione di ciascun
+processo allo stesso valore che hanno nel processo padre, un processo appena
+creato cioè appartiene sempre allo stesso raggruppamento e alla stessa
+sessione del padre. La differenza fra i due identificatori è che un processo
+può cambiare \acr{pgid} soltanto ad un valore che corrisponda al
+\textit{process group} di un altro processo della stessa sessione, oppure al
+suo stesso \acr{pid} (creando così un nuovo \textit{process group}). Se invece
+si modifica il \acr{sid} il processo viene automaticamente messo anche in un
+nuovo \textit{process group}, corrispondente al suo \acr{pid}.
+
+Per capire meglio il significato di questi identificatori vediamone subito
+l'uso concreto nella gestione del \textit{job control} della linea di comando.
+Una volta che si è completata la procedura di login (che esamineremo in
+dettaglio in \secref{sec:sess_login}), si avrà a disposizione una shell,
+associata ad un terminale (detto \textsl{terminale di controllo}), dalla quale
+eseguire i comandi, una delle caratteristiche della shell è quella di
+consentire di inviare un comando in \textit{background}, cioè di farlo
+eseguire distaccandolo dal terminale, che potrà essere utilizzato da altri
+comandi. Così un solo un comando alla volta potrà leggere e scrivere sul
+terminale (quello che viene detto in \textit{foreground}).
+
+Fra le funzionalità della shell c'è anche quella di consentire di concatenare
+più programmi in una sola riga di comando con le pipe, in tal caso, ed
+inoltre, anche quando si invoca un singolo programma, questo può sempre
+lanciare ulteriori sottoprocessi per eseguire dei compiti specifici.
+
+La shell farà si che tutti i processi che originano da un sola riga di
+comando vengano raggruppati in un unico \textit{process group}; questo perché
+i segnali inviati sul terminale con i comandi da tastiera (quelli illustrati
+in \secref{sec:sig_job_control}) vengono inviati a tutti i processi che fan
+parte del raggruppamento di \textit{foreground}, cioè quelli che stanno corre
+
+
+Per consentire l'utilizzo contemporaneo dello stesso terminale la shell deve
+essere in grado di garantire che solo un comando alla volta possa accedervi; 
+
+
+
+
+
+Lo stato del sistema può essere verificato con il comando \cmd{ps -je f}
+
+
+
+\subsection{Il login ed il terminale di controllo}

 \label{sec:sess_login}
 
 \label{sec:sess_login}
 

-L'organizzazione del sistema del \textit{Job Control}\footnote{viene
-  usualmente chiamata così la capacità del sistema di poter gestire più
-  processi (i \textit{job}) lanciati in contemporanea a partire da una shell,
-  di solito associata al terminale su cui si è appunto effettuato il login, in
-  modo da poter gestire la possibile presenza di più di un processo che
-  necessita di accedere a quest'ultimo.} è strettamente connessa alle modalità
-con cui un utente accede al sistema, collegandosi ad esso con un terminale,
-che sia questo realmente tale, come un VT100 collegato ad una seriale o
-virtuale, come quelli associati a schermo e tastiera, o semplicemente
-associato ad una connessione di rete. Per questo motivo in questa prima
-sezione prenderemo in esame le modalità di come avviene tutto ciò e di come il
-sistema (a partire da \cmd{init}) sia in grado di gestire il tutto.
-
-
-\subsection{Il login su terminale}
-\label{sec:sess_tty_log}
-
-La modalità più classica di accesso ad un sistema Unix è quella del login su
-terminale, che pertanto esamineremo per prima. Abbiamo già brevemente
-illustrato in \secref{sec:intro_kern_and_sys} le modalità con cui il sistema
-si avvia, e di come, a partire da \cmd{init}, vengano lanciati tutti gli altri
-programmi. Adesso prenderemo in esame in maniera dettagliata le modalità con
-cui si arriva a fornire ad un utente la shell che gli permette di lanciare i
-suoi comandi.
+L'organizzazione del sistema del \textit{Job Control} è strettamente connessa
+alle modalità con cui un utente accede al sistema, collegandosi ad esso con un
+terminale, che sia questo realmente tale, come un VT100 collegato ad una
+seriale o virtuale, come quelli associati a schermo e tastiera o ad una
+connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
+fine le differenze sono\footnote{in generale nel caso di login via rete o di
+  terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
+  ha origine l'esecuzione della shell.} nel device cui il kernel associa i
+file standard di \secref{sec:file_std_descr}, tratteremo solo il caso in
+questo è il classico terminale.
+
+Abbiamo già brevemente illustrato in \secref{sec:intro_kern_and_sys} le
+modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
+vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
+dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
+shell che gli permette di lanciare i suoi comandi su un terminale.

 
 Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
   distribuzione \textit{Slackware}, come alcune distribuzioni su dischetto, ed
 
 Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
   distribuzione \textit{Slackware}, come alcune distribuzioni su dischetto, ed


@@ -44,8 +110,8 @@ lanciati, ed in quali modalit
 anch'esso definito nello stesso file.
 
 Tralasciando la descrizione del sistema dei run level, (per il quale si
 anch'esso definito nello stesso file.
 
 Tralasciando la descrizione del sistema dei run level, (per il quale si

-rimanda alla lettura della pagina di manuale di \cmd{init} e di
-\file{inittab}) quello che comunque viene sempre fatto è di lanciare almeno
+rimanda alla lettura delle pagine di manuale di \cmd{init} e di
+\file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno

 una istanza di un programma che permetta l'accesso ad un terminale. Uno schema
 di massima della procedura è riportato in \secref{fig:sess_term_login}.
 
 una istanza di un programma che permetta l'accesso ad un terminale. Uno schema
 di massima della procedura è riportato in \secref{fig:sess_term_login}.
 


@@ -58,12 +124,13 @@ di massima della procedura 
 
 Un terminale, che esso sia un terminale effettivo, attaccato ad una seriale o
 ad un altro tipo di porta di comunicazione, o una delle console virtuali
 
 Un terminale, che esso sia un terminale effettivo, attaccato ad una seriale o
 ad un altro tipo di porta di comunicazione, o una delle console virtuali

-associate allo schermo, viene sempre visto attraverso attraverso un device
+associate allo schermo,  viene sempre visto attraverso attraverso un device

 driver che ne presenta un'interfaccia comune su un apposito file di
 dispositivo. Storicamente i primi terminali erano appunto terminali di
 telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia,
 \textit{tty}, che quello dei relativi file di dispositivo, che sono sempre
 driver che ne presenta un'interfaccia comune su un apposito file di
 dispositivo. Storicamente i primi terminali erano appunto terminali di
 telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia,
 \textit{tty}, che quello dei relativi file di dispositivo, che sono sempre

-della forma \texttt{/dev/tty*}.
+della forma \texttt{/dev/tty*}.\footnote{questo vale anche per i terminali
+  associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}

 
 Per controllare i terminali si usa di solito il programma \cmd{getty} (od una
 delle sue varianti), che permette di mettersi in ascolto sugli stessi. Alla
 
 Per controllare i terminali si usa di solito il programma \cmd{getty} (od una
 delle sue varianti), che permette di mettersi in ascolto sugli stessi. Alla


@@ -127,73 +194,6 @@ ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty}
 per ripetere da capo tutto il procedimento.
 
 
 per ripetere da capo tutto il procedimento.
 
 

-\subsection{Il login via rete}
-\label{sec:sess_net_log}
-
-Nel caso di un login via rete la cosa si fa leggermente diversa, in tal caso
-infatti non esiste un terminale fisico che \cmd{init} può tenere sotto
-controllo diretto, in quanto il collegamento deve avvenire tramite la rete.
-Quello che succede in questo caso è che nel procedimento di avvio del sistema
-si occupa di eseguire tutti i programmi che attivano la connesione di rete,
-per poi avviare tutti i programmi di servizio. 
-
-Questo viene in genere fatto attraverso una serie di script di shell, che
-vengono eseguiti in un preciso ordine (di nuovo la struttura del procedimento
-di avvio di System V va al di là di quanto ci interessa trattare) che
-eseguiranno i programmi richiesti, fra i quali sarà compreso (se
-l'amministratore lo avrà previsto) pure il server per le connessioni di rete. 
-
-Quest'ultimo sarà posto in esecuzione e si metterà in ascolto di eventuali
-connessioni sulla rete, una volta che la procedura di avvio sarà completata
-gli script termineranno ed il server si troverà ad avere \cmd{init} come
-processo padre.  
-
-
-\subsection{Il login attraverso X}
-\label{sec:sess_X_log}
-
-Quanto scritto finora riguardo i terminali è piuttosto diverso quando si ha a
-che fare con X. In tal caso infatti la procedura grafica per il login è
-gestira da un apposito programma (il cosiddetto \textit{Display Manager}, come
-\cmd{xdm}, che fa parte della distribuzione base di X o uno dei suoi molti
-cloni) che viene lanciato all'avvio insieme agli altri demoni, e che si cura
-di gestire la procedura di login, lanciare eventuali programmi che si vogliono
-attivare all'avvio (sia fondamentali, come il gestore delle fineste, che
-effimeri, come un notificatore di posta in arrivo).
-
-In questo caso 
-
-
-
-\section{Il \textit{Job control}}
-\label{sec:sess_job_control}
-
-Lo scopo del \textit{Job control} è quello di permettere ad un utente di poter
-sfruttare le capacità multitasking di un sistema Unix per eseguire in
-contemporanea più processi, pur potendo accedere, di solito, ad un solo
-terminale,\footnote{con X e con i terminali vituali tutto questo non è più
-  vero, dato che si può accedere a molti terminali in contemporanea, ma il
-  sistema è nato prima dell'esistenza di tutto ciò.} avendo cioè un solo punto
-in cui si può avere accesso all'input ed all'output degli stessi.
-
-
-
-\subsection{La struttura di base}
-\label{sec:sess_relation}
-
-Una volta che si è completata la procedura di login illustrata in
-\ref{sec:sess_login} si avrà a disposizione una shell dalla quale eseguire i
-comandi. Come illustrato in \secref{sec:intro_kern_and_sys} in un sistema Unix
-questi non sono altro che programmi come gli altri, inoltre essendo il sistema
-multitasking, non è neanche detto che un programma venga eseguito da un solo
-processo, infatti, oltre all'uso delle pipe, che permette di concatenare più
-con un solo comando, ed i sigoli programmi possono anche creare ulteriori
-sottoprocessi per eseguire alcuni compiti.
-
-Tutti questi processi, che originano da un solo comando iniziale, vengono
-raggruppati in quello che viene chiamato un \textit{process group}; quando
-viene creato ogni
-processo viene infatti mantenuto, 

 
 
 \subsection{I \textit{process group}}
 
 
 \subsection{I \textit{process group}}


@@ -215,6 +215,7 @@ processo viene infatti mantenuto,
 \label{sec:sess_shell}
 
 
 \label{sec:sess_shell}
 
 

+

 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"

diff --git a/signal.tex b/signal.tex
index 801e6ff1a8dc325156d238e85b4d3e4d772144d4..14e6d51dd03f51af9e8c478fe7a0a8b719056414 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -617,8 +617,9 @@ cui si trattano gli argomenti relativi.  Questi segnali sono:
   gestori per far si che un programma produca una qualche azione speciale
   se viene fermato e riavviato, come per esempio riscrivere un prompt, o
   inviare un avviso. 
   gestori per far si che un programma produca una qualche azione speciale
   se viene fermato e riavviato, come per esempio riscrivere un prompt, o
   inviare un avviso. 

-\item[\macro{SIGSTOP}] Il segnale ferma un processo (lo porta in uno stato di
-  sleep); il segnale non può essere né intercettato, né ignorato, né bloccato.
+\item[\macro{SIGSTOP}] Il segnale ferma un processo (lo porta cioè in uno
+  stato di sleep, vedi \secref{sec:proc_sched}); il segnale non può essere né
+  intercettato, né ignorato, né bloccato.

 \item[\macro{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
   ferma il processo interattivamente, ed è generato dal carattere SUSP
   (prodotto dalla combinazione \macro{C-z}), ed al contrario di
 \item[\macro{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
   ferma il processo interattivamente, ed è generato dal carattere SUSP
   (prodotto dalla combinazione \macro{C-z}), ed al contrario di