risistemato il capitolo sulle sessioni di lavoro
authorSimone Piccardi <piccardi@gnulinux.it>
Sat, 7 Sep 2002 22:42:01 +0000 (22:42 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sat, 7 Sep 2002 22:42:01 +0000 (22:42 +0000)
session.tex
signal.tex

index d3a0e4febe57d617587780caa081c02688c04bb7..cdc557360e7171ba87bed6c0715662f15134bfd9 100644 (file)
 \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}
 
-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
@@ -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
-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}.
 
@@ -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
-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
-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
@@ -127,73 +194,6 @@ ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty}
 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}}
@@ -215,6 +215,7 @@ processo viene infatti mantenuto,
 \label{sec:sess_shell}
 
 
+
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
index 801e6ff1a8dc325156d238e85b4d3e4d772144d4..14e6d51dd03f51af9e8c478fe7a0a8b719056414 100644 (file)
@@ -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. 
-\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