path: root/src/corsi/2014-linea_di_comando/log-lezione_6.log

21:04 <@valhalla> e iniziamo come al solito scaricando il materiale:
21:04 <@valhalla> wget http://www.lifolab.org/corsi/2014-linea_di_comando/riga_di_comando-lezione_6.tar.xz
21:04 <@valhalla> tar -x -v -f riga_di_comando-lezione_6.tar.xz
21:05 <@valhalla> questa sera parliamo di controllo dei processi
21:05 <@valhalla> (dimenticavo all'inizio il solito cd $DIRECTORY_SOLITA
21:06 <@valhalla> e dopo aver scaricato e scompattato prepariamo come sempre lo spazio per fare esercizi: ``cd lezione_6 && mkdir esercizi``
21:06 <@valhalla> (che come ricordate dalla volta scorsa, vi fa creare la directory esercizi solo se siete riusciti ad entrare nella dir lezione_6)
21:06 <@valhalla> e poi ``cd esercizi``
21:07 <@valhalla> la maggior parte dei comandi che abbiamo visto le altre volte finiva subito, quindi veniva lanciata, si aspettava la fine e poi si lanciava il comando successivo
21:07 <@valhalla> per`o ovviamente non tutti i programmi sono così
21:08 <@valhalla> alcuni stanno attivi a lungo perché elaborano dati, altri lanciano un'interfaccia grafica e stanno attivi finché non sono stati chiusi, ad esempio
21:08 <@valhalla> per fare gli esempi, invece, stasera usiamo un comodo comando che se ne sta fermo ad aspettare per un tot di secondi: sleep
21:09 <@valhalla> ad esempio, ``sleep 5`` si ferma per 5 secondi e poi finisce
21:09 <@valhalla> normalmente questo blocca la shell che state usando: questo perché il comando è in "foreground"
21:10 <@valhalla> ovvero, mentre gira quello è lui a prendersi l'input su stdin
21:10 <@valhalla> e in ogni momento in una shell può esserci solo un comando in foreground
21:11 <@valhalla> ci possono però essere più comandi in "background", che non hanno modo di ottenere input, ma continuano a girare fino a che non hanno finito lasciando la shell libera
21:12 <@valhalla> un modo per mandare un programma in background è mettere & alla fine del comando (cosa che avevamo visto alla prima lezione, e vi avevo promesso spiegazione)
21:12 <@valhalla> ad esempio, possiamo dare il comando ``sleep 100 &`` e subito dopo vediamo che la shell è libera, e ad esempio possiamo usare il comando ``jobs`` per vedere che programmi stanno girando in quella shell
21:13 <@valhalla> vediamo che il nostro sleep 100 è in status Running, ma noi abbiamo la shell a disposizione
21:14 <@valhalla> vedo che ci sono domande, passatemele pure
21:15 <@diego71> < pigro> il numero  visualizzato da jobs ?? il pid del job?
21:15 <@valhalla> no, è il numero di job in quella shell
21:15 <@valhalla> di PID invece parliamo dopo, e vediamo come si fa a vederlo
21:17 <@valhalla> nel frattempo, sleep dovrebbe aver finito, e se lanciamo ancora ``jobs`` vediamo che viene segnato come "Done"
21:17 <@valhalla> e poi sparisce del tutto
21:18 <@valhalla> adesso per comodità facciamo andare due comandi alla volta: mettendo una serie di comandi tra parentesi tonde si fa partire una nuove shell che esegue quei programmi, e poi possiamo mandare il tutto in background, ad esempio 
21:18 <@valhalla> ``(sleep 60 ; date) &``
21:18 <@valhalla> ancora ``jobs`` e vediamo che sta andando un job con tutti e due i comandi
21:18 <@valhalla> in questo modo, quando sleep ha finito vediamo stampare cose, e ci accorgiamo subito che ha finito
21:19 <@valhalla> mentre un programma è in foreground, possiamo passargli dei segnali
21:19 <@valhalla> che i programmi per unix riconoscono e agiscono di conseguenza
21:21 <@valhalla> con Ctrl-C si passa il segnale SIGINT, che interrompe il programma
21:21 <@valhalla> i programmi poi possono intercettare questi segnali e non farsi interrompere subito, ma ad esempio chiudersi come si deve, ma dipende dal programma 
21:21 <@valhalla> ad esempio, lanciamo ``(sleep 100 ; echo "sleep")``, poi premiamo Ctrl-C
21:22 <@valhalla> e con jobs possiamo controllare che non è rimasto niente, il processo è stato fermato
21:22 <@valhalla> domande fin qui?
21:23 <@valhalla> ok, proseguo
21:23 <@valhalla> un altro segnale utile è SIGSTOP, che invece interrompe il processo senza chiuderlo
21:23 <@valhalla> e poi lo si pu`o far riprendere
21:24 <@valhalla> come se lo si mettesse in pausa
21:24 <@valhalla> ad esempio ``(sleep 100 ; echo "sleep")`` poi premete Ctrl-Z
21:24 <@valhalla> e con ``jobs`` potete vedere che c'è quel processo che risulta "Stopped"
21:25 <@valhalla> finché lo lasciate lì non fa niente, non fa neanche passare i 100 secondi prima di chiudersi
21:25 <@valhalla> però ci sono dei comandi coi quali si può far riprendere un processo; con ``fg`` gli si dice di tornare in foreground e ricominciare a funzionare
21:26 <@valhalla> oppure, (per provare potete reinterrompere con Ctrl-Z un'altra volta)
21:26 <@valhalla> con ``bg`` si manda il processo bloccato in background, e lo si fa riprendere
21:27 <@valhalla> questo è il modo in cui si mandano in background dei processi se si è dimenticato di mettere & alla fine del comando, ad esempio
21:27 <@valhalla> con ``jobs``  potete sempre vedere che avete un processo in background, e dopo un po' finalmente vi stamperà "sleep"
21:27 <@valhalla> domande?
21:28 <@diego71> < gioque> che differenza c'?? tra sleep 100; echo "sleep" e (sleep 100; echo sleep)
21:28 <@valhalla> se si scrive ``sleep 100; echo "sleep"`` i due comandi vengono lanciati in successione dalla shell in cui si sta lavorando
21:28 <@valhalla> con le parentesi invece viene aperta una nuova shell ed è lei a lanciare in successione i due comandi
21:28 <@valhalla> col vantaggio che li si pu`o trattare come una cosa unica
21:29 <@valhalla> nel nostro caso per mandarli in foreground/background, ma anche ad esempio per leggere lo stdout di tutti uno dopo l'altro
21:30 <@valhalla> se si scrivesse solo ``sleep 100; echo "sleep" &`` sarebbe solo l'echo ad essere messo in background, sleep rimarrebbe in foreground
21:30 <@valhalla> altre domande?
21:31 <@valhalla> proseguo
21:31 <@valhalla> un'altro modo che abbiamo di mandare segnali ai processi è il comando kill
21:33 <@valhalla> di default anche lui manda il segnale SIGINT, mentre con l'opzione ``-9`` manda il segnale SIGKILL, che non può essere intercettato dai programmi e li fa chiudere ad ogni costo
21:34 <@valhalla> ad esempio, possiamo lanciare un paio di comandi in background: ``(sleep 100 ; echo "primo") &`` e poi ``(sleep 100 ; echo "secondo") &``
21:34 <@valhalla> ``jobs`` per vedere che ci sono
21:34 <@valhalla> e poi con ``kill %`` possiamo mandare il segnale SIGINT al secondo dei due
21:34 <@valhalla> e aspettando vedremo che solo il primo sarà arrivato a completamento
21:36 <@valhalla> (altre domande?
21:37 <@valhalla> < tiziano> cosa significa il carattere % in kill %?
21:37 <@valhalla> sta per "ultimo processo"
21:37 <@valhalla> lo si può usare anche con fg e bg
21:38 <@valhalla> oltre a % e basta si pu`o anche usare %<numero> e si lavora sul job con quel numero (come viene stampato dal comando jobs
21:39 <@valhalla> ad esempio, ``(sleep 100 ; echo "primo") &`` ``(sleep 100 ; echo "secondo") &`` e poi ``kill %1`` ucciderà il primo dei due, e lascerà andare il secondo
21:39 <@valhalla> altre domande?
21:39 <@valhalla> vado avanti
21:40 <@valhalla> un altro comando utile è ps, che stampa i processi in corso, e di default stampa non solo i processi della shell in corso, ma quelli del *terminale*
21:41 <@valhalla> ad esempio, mettiamoci un po' di roba con ``sleep 100 &`` ripetuto un paio di volte
21:41 <@valhalla> e poi ``ps``
21:41 <@valhalla> di default quello mostra il PID del processo, che era stato citato prima
21:42 <@valhalla> ovvero, un identificativo univoco del processo su *tutto* il sistema
21:42 <@valhalla> [ditemi sul canale di là per favore se mi state leggendo]
21:44 <@valhalla> dicevo, il PID non è univoco nel tempo: dopo un certo numero riparte a prendere i numeri rimasti liberi da processi che sono stati chiudi
21:44 <@valhalla> ma in ogni momento ci sarà un solo processo con quel PID
21:45 <@valhalla> usando l'opzione ``-f`` di ps si hanno un po' più di dettagli utili
21:46 <@valhalla> e in particolare UID, ovvero l'utente con i cui permessi sta girando quel processo e le opzioni con cui era stato lanciato il comando
21:47 <@valhalla> doamnde?
21:47 <@diego71>  pigro> che differenza c'?? tra PID e PPID?
21:47 <@valhalla> PPID è il PID del processo padre del processo elencato
21:47 <@valhalla> ovvero del processo che ha fatto partire il processo in questione
21:48 <@valhalla> con questo possiamo anche vedere la differenza tra ``sleep 100 ; echo "uno"`` e ``(sleep 100 ; echo "due")``
21:49 <@valhalla> ad esempio se facciamo ``sleep  100 ; echo "uno"
21:49 <@valhalla> ``
21:50 <@valhalla> poi ctrl-z per sospenderlo, e poi ps
21:50 <@valhalla> vediamo che ci sono una bash, sleep e il ps appena lanciato
21:51 <@valhalla> (poi usiamo fg per far tornare attivo lo sleep, o bg per mandarlo in background, cos`i va avanti
21:51 <@valhalla> se invece scriviamo ``(sleep 100 ; echo "due")``, poi sempre ctrl-z per fermarlo
21:52 <@valhalla> a quel punto con ``ps`` vediamo che ci sono due bash, uno sleep e poi ps
21:52 <@valhalla> e anzi, se usiamo ps -f vediamo che il parent della seconda bash e del ps è la prima bash
21:52 <@valhalla> mentre sleep ha come parent la seconda bash
21:52 <@valhalla> altre domande?
21:54 <@valhalla> ok, dovrei aver finito il backlog delle domande a cui avevo detto rispondo dopo
21:54 <@valhalla> se manca qualcosa, perfavore rifatela
21:54 <@valhalla> intanto vado avanti dicendo che:
21:54 <@valhalla> il PID pu`o essere usato anche come parametro di kill, per mandare segnali a processi non necessariamente sulla stessa shell
21:55 <@valhalla> ad esempio, diamo il solito ``sleep 100 &``
21:55 <@valhalla> vediamo che ci stampa il numero di job tra parentesi e dopo il suo pid
21:55 <@valhalla> possiamo controllare che lo sia con ps
21:55 <@valhalla> e poi possiamo ucciderlo con ``kill $PID``
21:55 <@valhalla> dove ovviamente al posto di $PID metterete il numero visto prima
21:56 <@valhalla> per trovare il PID di processi che non conoscete si usa sempre ps
21:56 <@valhalla> con ``ps -e -f`` si vedono tutti i processi del sistema
21:56 <@valhalla> anzi, meglio ``ps -e -f | less`` :)
21:57 <@valhalla> oppure ``ps -e -f | grep $NOME_DEL_PROGRAMMA_CHE_VI_SI_E_PIANTATO`` :)
21:58 <@valhalla> oppure in qualche caso è utile ``-u $NOME_UTENTE`` al posto di ``-e`` per vedere solo i processi di qualche utente
21:58 <@valhalla> domande?
22:00 <@diego71> < pigro> se per errore invio il kill al PPID
22:00 <@valhalla> pigro: uccidi il PPID (e a catena di solito anche tutti i suoi figli)
22:01 <@valhalla> a meno che si cerchi di killare un processo di qualche altro utente, nel qual caso lo si può fare solo se si è root
22:01 <@valhalla> altre domande
22:01 <@diego71> < gioque> per mettere in pause (tipo ctrl+z) un processo che non sia l'ultimo? (tipo se ho tre jobs e volgio mettere in stato stopped [non killed] il  n 2 come faccio?)
22:02 <@valhalla> porti in foreground il processo che vuoi stoppare con ``fg %2`` (ad esempio), e poi usi ctrl-z
22:02 <@valhalla> altre domande?
22:03 <@diego71> < polva> valhalla, c'era quella domanda su come distinguere tra shell e processo
22:03 <@valhalla> in che senso distinguere tra shell e processo?
22:04 <@diego71> < polva> riposto: ! valhalla ha detto che usare le parentesi fa avviare una nuova shell. a me si avvia sempre nella stessa. parte solo un altro comando
22:04 <@valhalla> avevamo visto l'esempio prima che con ps faceva vedere che tra i processi attivi c'era una nuova bash
22:05 <@valhalla> dalle 21:49 in poi nel log
22:05 <@valhalla> non si apre un nuovo *terminale*, solo una nuova bash all'interno nello stesso terminale, se era questo il tuo dubbio
22:05 <@valhalla> altre domande?
22:07 <@diego71> < tiziano> che segnale viene emesso esattamente con ctrl-z?
22:07 <@valhalla> SIGSTOP
22:08 <@valhalla> ultimo comando per la serata, il comando ``top``
22:08 <@valhalla> vi fa vedere i processi attivi in ordine di risorse usate, e aggiornandosi in tempo reale
22:09 <@valhalla> di default ordina per chi sta usando più CPU
22:09 <@valhalla> per i dettagli del significato dei vari campi pagina di manuale, che sennò ci vorrebbe una lezione intera
22:09 <@valhalla> ma se avete il computer piantato, è probabile che il colpevole sia uno dei primi nomi che saltano fuori :)
22:10 <@valhalla> e adesso possiamo proseguire con le domande rimaste
22:10 <@valhalla> (ah, poi q per uscire da top)
22:11 <@diego71> < pigro> a me prima non mi faceva il kill di un processo che era stoppato
22:11 <@valhalla> questo perché SIGINT è un segnale che il processo può elaborare
22:11 <@valhalla> di default quello che fa è uscire subito
22:11 <@valhalla> ma potrebbe anche fare qualcosa prima
22:12 <@valhalla> e se è stoppato, non pu`o neanche fare l'elaborazione "ah, un SIGSTOP, allora esco"
22:12 <@valhalla> ehm, SIGINT, non SIGSTOP
22:12 <@valhalla> sorry
22:12 <@valhalla> (nell'ultima riga)
22:12 <@valhalla> altre domande?
22:13 <@valhalla> < MrPan> htop è una versione "potenziata" del comando top ?
22:13 <@valhalla> pi`u o meno sì, nel senso che è un programma che fa cose simili
22:14 <@valhalla> però top c'è di default nei sistemi, htop va eventualmente installato
22:14 <@valhalla> altre domande?
22:15 <@valhalla> < gioque> se io ho messo subito in pausa con ctrl+z un processo  es (sleep 10; echo "test") e faccio fg di dopo 10 secondi mi scrive subito test, è normale o dovrebbe aspettarmi 10 secondi? 
22:15 <@valhalla> no, dovrebbe aspettarti 10 secondi
22:16 <@valhalla> per`o quei 10 secondi comprendono il tempo impiegato a mettere in pausa il processo dopo averlo lanciato
22:16 <@valhalla> e quelli da quando fai fg fino a quando stampa
22:17 <@valhalla> uhm, per`o in effetti ho appena provato, esce subito
22:18 <@valhalla> <@diego71> gioque: probabilmente ricordavo male io, la sleep aspetta 10 secondi a prescindere da ^Z
22:19 <@valhalla> la pagina di manuale in effetti non lo dice
22:19 <@valhalla> (ed è anche vero che nella vita reale no `e che lo si usi in questo modo)
22:20 <@diego71> < stefano_> leggendo il man mi chiedevo cosa volesse dire: "<Left>   force a screen redraw (if necessary)"
22:20 <@valhalla> significa che se si preme il tasto "freccia a sinistra" il programma top ridisegna lo schermo
22:21 <@valhalla> cosa che di solito fa ogni tot secondi, ma se premi lo fa nel momento in cui hai premuto
22:22 <@diego71> < erio> sleep 10 ; echo "OK". Poi ctrl Z e poi fg  ...per?? non mi stampa "ok"
22:22 <@valhalla> in realtà te l'ha stampato quando hai fatto ctrl-z, perché non avendo le () attorno hai sospeso il primo processo (lo sleep) e quindi il secondo (l'echo) è partito
22:22 <@valhalla> altre domande?
22:24 <@diego71> < polva> una domanda teorica. mi sfugge come mai sia necessario invocare un'altra bash per far fare due operazioni insieme.
22:24 <@diego71> ok, ti rispondo io
22:24 <@diego71> la comodita' e' che hai un solo processo figlio che fa tutti i comandi uno dopo l'altro
22:25 <@diego71> quindi se fai per esempio ^Z stoppi tutta la sequenza, invece che solo il primo come nel caso di erio
22:26 <@valhalla> e per poter raggruppare il tutto assieme ti serve un processo che abbia un numero, quindi si lancia un processo bash
22:27 <@valhalla> altre domande?
22:28 <@valhalla> allora, come gi`a detto all'inizio
22:28 <@valhalla> il corso con stasera è finito, nel materiale c'è un file approfondimenti.rst con link ad un paio di documenti utili
22:29 <@valhalla> in particolare, gli Appunti di Informatica Libera contengono fondamentalmente TUTTO :)
22:29 <@valhalla> mentre bash guide for beginners e poi advanced bash scripting guide sono utili per approfondire l'argomento shell
22:29 <@valhalla> settimana prossima faremo una serata dedicata a domande e risposte
22:30 <@valhalla> così se qualcuno ha qualche domanda arretrata che gli è venuta in mente tra una serata e l'altra può farla
22:32 <@valhalla> e detto questo, chiudo e mi metto a preparare i log