Lancio in background, controllo dei processi

Ripartiamo dall'uso del manuale in linea. Potrei non sapere quali comandi sono disponibili e, quindi, non sapere neanche quale pagina di manuale potrebbe interessarmi. Comunque, a chi è interessato a UNIX consiglio un buon libro, ad esempio tra quelli in bibliografia, gratuiti e non, ma, per ovviare in parte a questo problema, dalla shell si può lanciare il comando

$ xman &

La x indica che si tratta di un applicativo per X Window, cioè in grafica, quindi xman non può essere usato dal terminale, a partire dal quale si può avviare l'X Window System con il comando startx. Cliccando su ``Manual Page'' si fa apparire un'altra finestra con due menù. Cliccando su ``Sections'' e scegliendo la prima sezione, cioè quella dei comandi di utente, si fa apparire nella stessa finestra un ampio elenco di comandi, quindi si riesce a capire tra quali pagine di manuale si può scegliere. Cliccando sul generico comando si fa apparire la corrispondente pagina di manuale. Già, ma senso ha la & subito dopo il comando xman? Indica alla shell che il comando va eseguito in background. Senza tale precisazione, la shell rimarrebbe inutilizzabile fino alla chiusura dell'xman. Lanciando l'esecuzione in background si dà luogo a una ``biforcazione'' dell'esecuzione: mentre l'xman parte regolarmente, la shell ritorna subito utilizzabile, restituendo il suo prompt. Lanciando xman in background si può anche notare la situazione seguente.

$ xman &
[1] 545
$

Analizziamo queste tre righe, che mostrano anche come la shell sia essenziale al punto da non fornire informazioni inutili (anche in questo caso è bene ricordare che i terminali sui quali sono state sviluppate le prime shell erano piuttosto lenti). Ovviamente la prima è quella corrispondente al lancio in background di xman; sulla seconda la shell scrive due numeri progressivi per fornirci delle informazioni relative al processo appena lanciato; la terza riga corrisponde di nuovo al prompt. L'unica cosa nuova è nella seconda riga; perchè la shell ci comunica questi due numeri? Semplice: poiché il processo in questione viene lanciato in background, si ha una biforcazione dell'esecuzione (fork) e la shell non controlla direttamente l'evoluzione di tale processo, che in questo caso verrà controllato dagli eventi generati dal mouse. Tuttavia, UNIX consente un monitoraggio completo e dettagliato su tutti i processi in esecuzione e un pieno controllo su di essi. Quindi la shell, al momento di mandare un processo in background, ci dà le informazioni necessarie a controllarlo successivamente. Tra parentesi quadre si trova un numero proprio della shell in esecuzione, nel caso in questione il numero 1 indica che si tratta del primo ``job'' che la shell utilizzata ha lanciato in background da quando è stata avviata. Il numero presentato accanto è il cosiddetto PID, identificatore di processo; anch'esso è un numero progressivo, anche se non è specifico della shell in esecuzione: a partire da quando viene avviato il Sistema Operativo, ad ogni processo, per qualunque utente venga lanciato, viene assegnato un numero progressivo di PID, che ovviamente, non può che essere maggiore del numero di ``job''.
A questo punto ritengo utile un confronto che permette di capire meglio i concetti di processo e di multitasking. Per ms windows 98 si parla di ``cooperative multitasking''. Il vero multitasking, per esempio quello offerto da UNIX, è più precisamente detto ``preemptive multitasking'', dove ``preemptive'' indica che il Sistema Operativo (più precisamente, il kernel) può in qualsiasi momento fare ciò che vuole dei processi in esecuzione, per esempio in fase di emergenza si può terminare forzatamente l'esecuzione di un processo ``impazzito''; mi sembra normale che in qualunque edificio di una certa importanza si preveda un'uscita di sicurezza... ``Cooperative multitasking'' significa che nell'ambiente software offerto si cerca di simulare il multitasking. windows 98 è basato su ms dos, che è rigorosamente monotasking, e si limita a ``cooperare'' con gli applicativi (in realtà, come ho detto, con windows non è possibile parlare di processi propriamente detti), decidendo poco più dell'ordine con cui devono ``passarsi la staffetta'', senza avere però un controllo completo sulla loro esecuzione. Infatti è esperienza comune che i folleggiamenti di un qualsiasi applicativo per windows (tutt'altro che rari) possono costringere a riavviare il computer, il che potrebbe non essere ragionevole in molti casi se si sta facendo qualcosa di importante. È ovvio che un ambiente siffatto non vi dà molte informazioni su quello che sta facendo esattamente... non vi sarebbero molto utili. Al contrario, con UNIX, se un applicativo fa bizze, siete costretti a riavviare il computer solo se il sistema si è inchiodato a tal punto da non rispondere più neanche a una shell, magari anche remota: in uno dei pochi casi di emergenza che ho dovuto gestire, comunque dovuto solo a sovraccarico, ho risolto il problema tramite un collegamento remoto, anche questo possibile solo per un Sistema Operativo server con una shell...
Torniamo al nostro xman, al suo numero di job e al suo PID. Per elencare i processi che il Sistema Operativo sta eseguendo per noi, basta usare il comando

$ ps

Nel caso in questione UNIX (Linux) risponde

  PID TTY STAT TIME COMMAND
  344   1 S    0:00 -bash 
  364   1 S    0:00 sh /usr/X11R6/bin/startx 
  365   1 S    0:00 xinit /home/pratesi/.xinitrc -- 
  368   1 S    0:00 sh /home/pratesi/.xinitrc 
  372   1 S    0:00 kwm 
  373   1 S    0:00 kaudioserver 
  374   1 S    0:00 kwmsound 
  375   1 S    0:00 kfm 
  377   1 S    0:00 krootwm 
  378   1 S    0:00 kpanel 
  379   1 S    0:00 kbgndwm 
  388   1 S    0:00 maudio -media 1 
  395   1 S    0:00 kikbd 
  399   1 S    0:01 rxvt -ls -sr -title rxvt 2.4.7 - 28 August 1998 -fn 10x20 -b
  400  p3 S    0:00 -bash 
  420  p3 S    0:07 color-vim unix_shell.tex 
  524   1 S    0:00 rxvt -ls -sr -title rxvt 2.4.7 - 28 August 1998 -fn 10x20 -b
  525  p4 S    0:00 -bash 
  537  p3 S    0:00 xdvi.bin -name xdvi main 
  544  p3 S    0:00 gs -sDEVICE=x11 -dNOPAUSE -q -dDEVICEWIDTH=623 -dDEVICEHEIGH
  545  p4 S    0:00 xman 
  556  p4 R    0:00 ps

Si può notare che molti processi hanno a che fare con ``x'' con ``k'', dato che in questo momento sto utilizzando l'ambiente grafico (X Window System) con il desktop KDE. Comunque, essendo mattina, ho ancora pochi processi in funzione e tutti hanno un PID piuttosto basso, come si può notare nella prima colonna. In questo contesto direi di concentrarsi solo sulla prima e sull'ultima colonna della risposta ottenuta. Nell'ultima riga è possibile notare proprio l'ultimo processo lanciato, cioè ps, con PID 556; la penultima riga corrisponde proprio a xman e al suo PID, cioè 545. Che cosa possiamo fare di questo numero 545? Per esempio, possiamo per esercizio terminare l'esecuzione di xman tramite shell anziché tramite mouse, tramite il comando

$ kill -9 545

Ovviamente, ogni utente può controllare solo i propri processi: normalmente non avete il potere di ``uccidere'' i processi degli altri (UNIX non è una giungla...), a meno che non assumiate l'identità di ``root''. Un'altra precisazione: la shell da cui lanciamo xman ci fornisce il numero di ``job'' e il PID del processo che manda in background; quest'ultimo può essere controllato anche tramite un'altra shell (quindi, ad esempio, tramite un altro terminale grafico). Ovviamente, però, ogni shell ha una sua numerazione progressiva dei job e, quindi, il numero di job fornitoci può identificare il processo solo per la shell che lo ha lanciato in background; su un'altra shell bisogna far riferimento al PID. È anche possibile mandare in background un processo inizialmente lanciato in foreground, cioè senza &: basta agire sulla shell stoppando il processo con CTRL-Z e quindi riavviarlo in background con il comando bg. Anche in questo caso la shell ci fornisce il numero di job e il PID del processo in questione. Se un processo lanciato in background da una shell termina, alla prima occasione utile, tale shell ce lo comunica indicando anche se il processo è terminato correttamente o, eventualmente, con quale condizione di errore. In questo caso, se si batte un invio senza un comando, la shell ci comunica

[1]+  Killed                  xman

Infine: come si termina l'esecuzione di una shell? Con CTRL-D, logout, oppure exit. La distinzione in merito è sottile e interessante, ma credo che vada al di là degli scopi di questa introduzione. Normalmente (e su Linux RedHat è così) va bene in tutti e 3 i modi, anche se su Linux Slackware in generale questo non è vero.