From 30cb53edd77ad2afe22ed9541942ef1c6a923a5b Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Fri, 13 Sep 2002 13:54:59 +0000 Subject: [PATCH] Completate sessioni, aggiunti riferimenti a dove sta la roba nel kernel, verificato il comportamento di setpgid e setsid, iniziata la sezione sui terminali di controllo --- session.tex | 111 +++++++++++++++++++++++++++++++++++----------------- 1 file changed, 75 insertions(+), 36 deletions(-) diff --git a/session.tex b/session.tex index c5c1d24..a7cd2e8 100644 --- a/session.tex +++ b/session.tex @@ -18,9 +18,10 @@ il cui scopo 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 virtuali 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. + accedere a molti terminali in contemporanea da una singola postazione di + lavoro, 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{Una panoramica introduttiva} @@ -35,20 +36,20 @@ del kernel; in particolare il kernel deve assicurare sia la presenza di un driver per i terminali abilitato al \textit{job control} che quella dei relativi segnali illustrati in \secref{sec:sig_job_control}. -In un sistema che supporta il \textit{job control} una volta completato il -login (che esamineremo in dettaglio in \secref{sec:sess_login}), l'utente avrà -a disposizione una shell dalla quale eseguire i comandi e potrà iniziare -quella che viene chiamata una \textsl{sessione}, che riunisce (vedi -\secref{sec:sess_proc_group}) tutti i processi eseguiti all'interno dello -stesso login. +In un sistema che supporta il \textit{job control}, una volta completato il +login, l'utente avrà a disposizione una shell dalla quale eseguire i comandi e +potrà iniziare quella che viene chiamata una \textsl{sessione}, che riunisce +(vedi \secref{sec:sess_proc_group}) tutti i processi eseguiti all'interno +dello stesso login (esamineremo tutto il processo in dettaglio in +\secref{sec:sess_login}). Siccome la shell è collegata ad un solo terminale (che viene usualmente -chiamato \textsl{terminale di controllo}) un solo comando alla volta (quello -che viene detto in \textit{foreground}), potrà scrivere e leggere dal -terminale. La shell però può eseguire anche più comandi in contemporanea, -mandandoli in \textit{background} (aggiungendo una \cmd{\&} alla fine del -comando), nel qual caso essi saranno eseguiti senza essere collegati al -terminale. +chiamato \textsl{terminale di controllo}, vedi \secref{sec:sess_ctrl_term}) un +solo comando alla volta (quello che viene detto in \textit{foreground}), potrà +scrivere e leggere dal terminale. La shell però può eseguire anche più comandi +in contemporanea, mandandoli in \textit{background} (aggiungendo una \cmd{\&} +alla fine del comando), nel qual caso essi saranno eseguiti senza essere +collegati al terminale. Si noti come si sia parlato di comandi e non di programmi o processi; fra le funzionalità della shell infatti c'è anche quella di consentire di concatenare @@ -99,12 +100,14 @@ e quali sono terminati. Come accennato in \secref{sec:sess_job_control_overview} nel job control i processi vengono raggruppati in \textit{process group} e \textit{sessioni}; per far questo vengono utilizzati due ulteriori identificatori (oltre quelli -visti in \secref{sec:proc_pid}) che il kernel associa a ciascun processo: -l'identificatore del \textit{process group} e l'identificatore della -\textsl{sessione}, che vengono indicati rispettivamente con le sigle -\acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo \type{pid\_t}. I -valori di questi identificatori possono essere visualizzati dal comando -\cmd{ps} usando l'opzione \cmd{-j}. +visti in \secref{sec:proc_pid}) che il kernel associa a ciascun +processo:\footnote{in Linux questi identificatori sono mantenuti nei campi + \var{pgrp} e \var{session} della struttura \var{task\_struct} definita in + \file{sched.h}.} l'identificatore del \textit{process group} e +l'identificatore della \textsl{sessione}, che vengono indicati rispettivamente +con le sigle \acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo +\type{pid\_t}. I valori di questi identificatori possono essere visualizzati +dal comando \cmd{ps} usando l'opzione \cmd{-j}. Un \textit{process group} è pertanto definito da tutti i processi che hanno lo stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con @@ -190,6 +193,7 @@ da un gruppo ad un altro con la funzione \func{setpgid}, il cui prototipo \begin{errlist} \item[\macro{ESRCH}] Il processo selezionato non esiste. \item[\macro{EPERM}] Il cambiamento non è consentito. + \item[\macro{EACCESS}] Il processo ha già eseguito una \func{exec}. \item[\macro{EINVAL}] Il valore di \param{pgid} è negativo. \end{errlist} } @@ -231,31 +235,66 @@ sessione ad un processo La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo \textit{process group} di cui esso diventa leader (come per i \textit{process - group} un processo si dice leader di sessione se il suo \acr{sid} è uguale -al suo \acr{pid}). Inoltre il processo non avrà più un terminale di -controllo. - -La funzione ha successo soltanto se il processo non è già leader per un + group} un processo si dice leader di sessione\footnote{in Linux la proprietà + è mantenuta in maniera indipendente con un apposito campo \var{leader} in + \var{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}). +Infine la funzione distacca il processo da ogni terminale di controllo +(torneremo sull'argomento in \secref{sec:sess_ctrl_term}) cui fosse in +precedenza associato. + +La funzione ha successo soltanto se il processo non è già leader di un \textit{process group}, per cui per usarla di norma si esegue una \func{fork} e si esce, per poi chiamare \func{setsid} nel processo figlio, in modo che, avendo questo lo stesso \acr{pgid} del padre ma un \acr{pid} diverso, non ci -siano possibilità di errore. Questa funzione viene usata di solito nel -processo di login (per i dettagli vedi \secref{sec:sess_login}) per -raggruppare in una sessione tutti i comandi eseguiti da un utente dalla sua -shell. +siano possibilità di errore.\footnote{potrebbe sorgere il dubbio che, per il + riutilizzo dei valori dei \acr{pid} fatto nella creazione dei nuovi processi + (vedi \secref{sec:proc_pid}), il figlio venga ad assumere un valore + corrispondente ad un process group esistente; questo viene evitato dal + kernel che considera come disponibili per un nuovo \acr{pid} solo valori che + non corrispondono ad altri \acr{pid}, \acr{pgid} o \acr{sid} in uso nel + sistema.} Questa funzione viene usata di solito nel processo di login (per i +dettagli vedi \secref{sec:sess_login}) per raggruppare in una sessione tutti i +comandi eseguiti da un utente dalla sua shell. \subsection{Il terminale di controllo} \label{sec:sess_ctrl_term} -Come accennato in \secref{sec:sess_job_control_overview} ad ogni sessione di -lavoro di norma viene associato un terminale di controllo. Alla creazione -della sessione con \func{setsid} infatti ogni associazione con un precedente -terminale di controllo viene spezzata, ed il processo dovrà riottenere (se -necessario, vedi \secref{sec:sess_daemon}), un terminale di controllo. +Come accennato in \secref{sec:sess_job_control_overview}, nel sistema del +\textit{job control} i processi all'interno di una sessione fanno riferimento +ad un terminale di controllo (ad esempio quello su cui si è effettuato il +login), sul quale effettuano le operazioni di lettura e +scrittura,\footnote{nel caso di login grafico la cosa può essere più + complessa, e di norma l'I/O è effettuato tramite il server X, ma ad esempio + per i programmi, anche grafici, lanciati da un qualunque emulatore di + terminale, sarà quest'ultimo a fare da terminale (virtuale) di controllo.} e +dal quale ricevono gli eventuali segnali da tastiera. + +A tale scopo lo standard POSIX.1 prevede che ad ogni sessione possa essere +associato un terminale di controllo (e non più di uno); in Linux questo viene +realizzato mantenendo fra gli attributi di ciascun processo anche il terminale +di controllo. \footnote{Lo standard POSIX.1 non specifica nulla riguardo + l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura + \var{task\_struct}, nel campo \var{tty}.} +In generale ogni processo eredita dal padre, insieme al \acr{pgid} e al +\acr{sid} anche il terminale di controllo. In questo modo tutti processi +originati dallo stesso leader di sessione mantengono lo stesso terminale di +controllo. + +Alla creazione di una nuova sessione con \func{setsid} ogni associazione con +il precedente terminale di controllo viene cancellata, ed il processo che è +divenuto un nuovo leader di sessione dovrà riottenere (qualora sia necessario, +cosa che come vedremo in \secref{sec:sess_daemon} non è sempre vera), un +terminale di controllo. In generale questo viene fatto automaticamente dal +sistema quando il leader di sessione apre il suo primo terminale\footnote{a + meno di non avere richiesto esplicitamente che questo non diventi un + terminale di controllo con il flag \macro{O\_NOCTTY} (vedi + \secref{sec:file_open}). In questo Linux segue la semantica di SVr4; BSD + invece richiede che il terminale venga allocato esplicitamente con una + \func{ioctl} con il comando \macro{TIOCSCTTY}.} che diventa automaticamente +il terminale di controllo. -Le modalità con cui \subsection{Dal login alla shell} -- 2.30.2