Amministrare GNU/Linux - Cia

38 CAPITOLO 1. L’ARCHITETTURA DI UN SISTEMA GNU/LINUX1.3.4 Sessioni di lavoro e job controlLa gestione delle sessioni di lavoro è uno dei punti più oscuri della interfaccia a linea di comandodi un sistema unix-like. Essa origina dagli albori del sistema, quando ci si poteva collegare soloattraverso un terminale, che era l’unica modalità di interazione con il sistema. Questo allora haportato a tracciare una distinzione fra i processi interattivi (che quindi erano associati ad unterminale) e quelli non interattivi slegati da un terminale (che abbiamo già trovato nell’outputdi ps, nella colonna TTY). In genere questi ultimi sono tradizionalmente chiamati demoni, e sonoprogrammi utilizzati dal sistema per compiere una serie di compiti di utilità, (come spedirela posta, eseguire lavori periodici, servire pagine web, ecc.) anche quando nessun utente ècollegato ad un terminale. Per questo lavorano come suol dirsi “in background” e non hannonessun terminale di riferimento.Avendo a disposizione un solo terminale, se questo fosse stato occupato da un solo processoalla volta, non si sarebbero potute sfruttare le capacità di multitasking del sistema, per questovenne introdotta un’interfaccia, quella delle sessioni di lavoro e del job control, che permettessedi lanciare ed usare più processi attraverso un solo terminale. Oggi, con la possibilità di averepiù console virtuali, e con l’interfaccia grafica che non fa riferimento ad un terminale, questoproblema non c’è più, ma l’interfaccia è rimasta e mantiene comunque una sua utilità, ad esempioin presenza di una connessione diretta via modem in cui si ha a disposizione un solo terminale,e si devono eseguire compiti diversi.Questo però ha comportato che la distinzione fra processi interattivi e non non sia più cosìsemplice, non potendosi più basare sulla semplice presenza o meno di un terminale di controlloperché, con l’introduzione delle interfacce grafiche, si possono eseguire anche programmi con cuiè possibile interagire, (attraverso di esse), senza che questi siano associati a nessun terminale.Comunque è sempre possibile identificare questi ultimi, in quanto discenderanno dal processoche gestisce l’accesso attraverso l’interfaccia grafica.Si tenga comunque presente che dal punto di vista del kernel non esiste nessuna differenzafra processi interattivi e non, esso si limita a mettere a disposizione alcune risorse che possonoessere utilizzate per realizzare il controllo di sessione, (in sostanza degli identificatori aggiuntivicome il session id ed il process group id e le funzioni per impostarne il valore, e l’invio dei segnalirelativi alla gestione), che poi viene realizzato completamente in user space, secondo la modalitàclassica ereditata dai primi Unix.Per capire meglio il significato di tutto questo, e della differenziazione fra processi interattivie non, occorre illustrare una caratteristica fondamentale dell’interfaccia a riga di comando. Lashell infatti, nel momento in cui lancia un programma, si cura sempre di automaticamente trefile, che sono immediatamente disponibili. 54 Essi sono rispettivamente lo standard input, lostandard output e lo standard error. Dato che questi sono i primi tre file aperti e lo sono inquesta sequenza, ad essi vengono assegnati rispettivamente i file descriptor 0, 1 e 2. 55Convenzionalmente 56 un programma legge il suo input dal primo file descriptor, scrive l’outputsul secondo, e gli eventuali errori sul terzo. Quando un processo è interattivo (cioè è statolanciato direttamente da una shell interattivamente) tutti e tre questi file sono associati al terminalesu cui si stava operando, e l’interfaccia dei terminali (cioè quella dei dispositivi di questotipo) fa sì che in lettura il terminale fornisca quanto scritto sulla tastiera e che quanto scrittosul terminale venga stampato sullo schermo.La gestione delle sessioni di lavoro deriva direttamente dalla procedura di login su terminale.54 torneremo su questo in sez. 2.1.5.55 come accennato in sez. 1.2.2 il sistema mantiene anche una lista dei file aperti dai vari processi, ciascunprocesso a sua volta ha una lista dei file che ha aperto, il cui indice è appunto un numero chiamato file descriptor,per maggiori dettagli riguardo a questa problematica si può consultare la sezione 6.1 di [1].56 si tenga presente che è solo una convenzione, si può tranquillamente scrivere un programma che si comportain modo diverso, scrivendo e leggendo da un file qualunque.