Newsgroup: it.comp.os.linux.iniziare
Titolo: riavviare dopo installazione/aggiornamento di applicazioni

ï¿œ necessario/consigliabile?
Per essere sicuri che il tutto sia stato registrato, scritto, applicato...

 Per essere sicuri che il tutto sia stato registrato, scritto, applicato...
 
Dipende da cosa e` stato aggiornato.
 
Se, per es., si tratta di "firefox",
allora basta chiuderlo e riaprirlo.
Se si tratta di "glibc", direi che
il reboot (forse anche solo init 1)
e` d'obbligo.
 
lsof | gawk '$5 == "DEL" {print}'
 
Riporta i file aperti da qualcuno e
rimpiazzati da un update (di solito).
 
YMMV
 
bye,
 
-- 
 
piergiorgio

 applicato...
 
A parte il kernel (e anche lì solo se vuoi usare quello nuovo) no. Basta 
eventualmente riavviare gli applicativi ma spesso e volentieri ci pensa il 
gestore dei pacchetti a farlo, dopo l'installazione.

 YMMV
 
-- 
Tanti saluti
 


Non e' che sia obbligatorio, semplicemente continui ad usare nei 
programmi caricati le vecchie versioni delle lib aggiornate
 

 
 
 
-- 
 
piergiorgio

 programmi caricati le vecchie versioni delle lib aggiornate
 
Basta riavviare questi programmi. No?
 

 programmi caricati le vecchie versioni delle lib aggiornate
 
Certo, e se l'upgrade riguarda un problema
di sicurezza lascio tutto cosi`...
 
Ovviamente "obbligatorio" forse andava fra
virgolette, ma il senso e` che se si vuole
avere l'aggiornamento, si "deve" far ripartire
il tutto...
 
Altrimenti, cosa si aggiorna a fare?
 
bye,
 
-- 
 
piergiorgio

 Basta riavviare questi programmi. No?
 
Non tutti sono semplicemente riavviabili.
 
Io ho /usr montata ro e questo su Fedora,
il che vuol dire che /bin, /sbin e /lib
sono link dentro /usr.
 
Quando faccio un aggiornamento, devo
montare /usr rw e poi, ovviamente ro.
 
A volte funziona senza problemi, a volte si
deve uscire dall'account, a volte si deve
andare fuori X11 (init 3), a volte init 1 ed
a volte reboot.
Sempre nel caso di aggiornamenti user space.
 
L'ultima volta, systemd aveva linkato delle
librerie, che erano state aggiornate, e neanche
init 1 lo ha smosso.
A volte, vi sono dei programmi di sistema che
far ripartire e` piu` costoso di un reboot.
 
Insomma non e` affatto cosi` semplice come
sembra e forse non e` neanche cosi` trasparente
come dovrebbe.
 
bye,
 
-- 
 
piergiorgio

 Per essere sicuri che il tutto sia stato registrato, scritto, applicato...
 
Non stai su Windows
 

 ro.
 
Mi pare un caso un po' particolare, no? Che un desktop abbia /usr montata 
read only intendo. Fra l'altro a te servono due riavvii manco uno.

 applicato...
 
con *buntu (probabilmente con debian e altre distribuzioni) dopo 
l'aggiornamento, se è necessario riavviare, trovi in /var/run i file:
- reboot-required
- reboot-required.pkgs
 
nel secondo file c'è la lista dei pacchetti che richiedono il riavvio
-- 
bye
!(!1|1)
 


Certo, non serve riavviare il sistema, anche se dipende dalle praticita
Ad esempio se una lib usata da un DE grafico occorre  disconnettersi 
oppure andare a runlevel 1
Per il kernel invece occorre riavviare altrimenti si continua ad usare 
anche qui la versione caricata
Esistono dei modi per evitare il riavvio dopo un cambio kernel ma sono 
per lo piu usati in ambito server
 


Non proprio,tecnicamente solo i programmi che usano la libreria
Questo perche' in linux (al contrario di win) la lib aggiornata viene 
proprio sostituita
In win invece la vecchia lib (dll) continua a rimanere al suo posto, 
viene solo scritto nel registry il comando di sostituzione e poi al 
riavvio il sistema opera effettivamente la sostituzione
 
 

 allora basta chiuderlo e riaprirlo.
 
se si aggiorna un programma mentre ï¿œ aperto che succede?
 


durante l'aggiornamento io di solito chiudo tutto, ma se per sbaglio 
lascio un programma aperto?
Possibile che possa aggiornarsi mentre è in funzione?
 

 Possibile che possa aggiornarsi mentre è in funzione?
 
Certo che è possibile. Di principio continui ad usare la vecchia versione, 
però dipende da come è strutturato il programma/pacchetto. 

 
 
 
-- 
 
piergiorgio

 read only intendo. Fra l'altro a te servono due riavvii manco uno.
 
No, ne basta uno. Perche` due?
 
Forse non mi sono spiegato bene: quello che
la /usr rw/ro mette in evidenza e` che vi
sono casi in cui si *deve* riavviare ovvero
casi in cui e` piu` *pratico* farlo.
 
Il resto e` solo leggenda metropolitana.
 
bye,
 
-- 
 
piergiorgio

 Non proprio,tecnicamente solo i programmi che usano la libreria
 
Se il programma *non* si puo` far ripartire,
oppure farlo ripartire (vedi dbus) costa piu`
di un reboot?
 
Ed inoltre, come si fa a sapere quale programma
usi quale libreria?
 
Una domanda: avete mai *provato* la cosa?
Intendo, per es. /usr in ro...
 
Perche`, usando Fedora, che praticamente ha
aggiornamenti giornalieri, mi ha fornito una
certa esperienza sulla cosa.
 
Diciamo che un 10% delle volte il reboot e`
la cosa piu` rapida da fare.
Un 85% basta init 3, init 5.
Un 5% va via senza problemi.
 
bye,
 
pg
 
-- 
 
piergiorgio

 se si aggiorna un programma mentre ï¿œ aperto che succede?
 
Dipende, firefox dovrebbe dirtelo e chiedere
di ripartire. Tanto per dirne uno.
 
Di solito il programma che e` in funzione
continua ad essere quello vecchio e dovrebbe
continuare ad andare senza intoppi
 
Vi possono essere problemi qualora un file
del pacchetto, il cui accesso avviene magari
dinamicamente, venga modificato in maniera
incompatibile dall'aggiornamento.
Allora, non appena il programma in esecuzione
tentasse di accedervi, vi potrebbero essere problemi.
 
Cioe`, firefox, tanto per rimanere in tema, non
e` solo l'eseguibile stesso, ma tutto un gruppo
di file.
Se per caso FF, magari quando si va in un menu
particolare, dovesse andare a leggersi qualche
informazione, chesso` /usr/lib/firefox/menu_xyz.layout,
allora potrebbero essere problemi qualora quel
file, una volta aggiornato, non sia piu` compatibile
con la versione di FF che e` in esecuzione (e non
e` la stessa dell'aggiornamento).
 
Successo anche questo...
 
bye,
 
-- 
 
piergiorgio

 Un 5% va via senza problemi.
 
Scusa pero' io adesso ho la Debian stabile, ma prima avevo la testing e
anche li' c'erano aggiornamenti giornalieri. Ebbene: MAI una volta,
tranne per il kernel e non sempre, ho dovuto o m'e' stato chiesto di
riavviare.
Ci vorrebbe un esperto di gestori di pacchetti, pero' forse, se dici
cosi' di rpm, allora dipende da apt che ha i poteri della Super Mucca.
 
-- 
Tanti saluti
 

 cosi' di rpm, allora dipende da apt che ha i poteri della Super Mucca.
 
No, nessuno funziona. Punto.
Ne` rpm, ne` yum, ne` apt o dpkg.
 
Semplicemente *ignorano* il fatto che vi siano
file aperti (in /usr, di solito).
 
Ripeto, avendo /usr read-only mette in evidenza
la situazione quando si fa un aggiornamento.
Infatti, ripeto ancora, dopo il remount rw, il
successivo remount ro non funziona quasi mai:
 
/usr: device or resource busy
 
Il mini-script che ho fornito riporta i file
aperti e cancellati.
Verificando con quello, si vede che vi sono
processi *attivi* che hanno, solitamente,
librerie aperte in /usr, le quali sono state
aggiornate (quindi il file aperto deve essere
rimosso e /usr non puo` essere montata ro).
 
Ed ancora, per chi non avesse capito, a quel
punto far ripartire tutti i servizi che tengono
le librerie aperte e` piu` *costoso* di un reboot.
Specie su di un desktop.
 
Una volta, forse 10 anni fa, quando il sistema
era piu` semplice (o meno complesso) molto
probabilmente era piu` facile far ripartire
quattro task ed avere un sistema "pulito".
 
Oggi, tra X11, gdm, dbus (orrore) rimane sempre
qualcosa fuori, magari in maniera indiretta.
 
bye,
 
-- 
 
piergiorgio

 No, ne basta uno. Perche` due?
 
Non lo so, se devi riavviare dopo l'installazione per rimontare /usr in 
read-only immagino tu lo debba fare anche prima per montarla in rw.

 del tool che fa l'upgrade?
 
Mi sono fidato sempre ciecamente; e per anni.
Pero'... ci sta un pero':
1) Uso dselect, quindi niente gestori grafici.
2) Aggiorno sempre e solo a mano.
3) Quando aggiorno mando sempre giu' prima X, se per caso e' avviato.
 
Questa mia e', anche in accordo con quel che dici poi, una situazione,
che riconosco come abbastanza, per non dire molto, particolare.
 
Grazie delle info che dici nel seguito (che non riporto), che mostrano
che vedevo giusto quando mi venivano i brividi solo a pensare di
updatare il sistema da X o comunque con X in gioco.
 
-- 
Tanti saluti
 

 read-only immagino tu lo debba fare anche prima per montarla in rw.
 
mount /usr -o remount,rw
 
Questo mi ha sempre funzionato, senza reboot.
 
Ovviamente, in /etc/fstab c'e` /usr con ro,
quindi al reboot successivo, qualora necessario,
viene automaticamente montata ro.
 
Tra l'altro, pare che avere /usr separata sia
una cosa poco supportata anche se Fedora, a
furor di popolo, la monta direttamente da
initramfs (dopo /, chiaramente) per averla
disponibile da subito.
 
bye,
 
-- 
 
piergiorgio

 updatare il sistema da X o comunque con X in gioco.
 
Figurati!
Ripeto, hai ragione e fai benissimo.
 
bye,
 
-- 
 
piergiorgio


 
 
Su questo sono d'accordo, faccio prima a riavviare che stare a dare il 
comando per il runlevel


 comando per il runlevel
 
Esatto, questo e` proprio il punto.
 
Prima di aver capito quale runlevel sia
quello giusto, si fa prima a ripartire.
 
Io, di solito, se init 3 non basta, faccio
ripartire con o senza kexec.
Quindi, nel mio caso, considero init 3 meno
costoso di un reboot, ma dopo quello, nel
caso non sia sufficiente, il reboot e` piu`
conveniente.
 
bye,
 
pg
 
-- 
 
piergiorgio


A runlevel 1 nessuna libreria di X (e di chi sta sopra ad X) dovrebbe 
essere attiva
A parte che se ce ne sono e' un baco (1), basta qualche kill
 
 
1) L' unica  eccezione e' per una libreria occupata in kernel mode, ma 
nessuna libreria di X dovrebbe esserlo
 
 

 nessuna libreria di X dovrebbe esserlo
 
Ancora con X.
Comunque, *nessuna* libreria user space
dovrebbe essere linkata nel kernel in
modo *dinamico*.
 
Infatti, il kernel ha le sue lib (libcrc32,
per esempio, e` direttamente in kernel).
 
bye,
 
-- 
 
piergiorgio

 Per essere sicuri che il tutto sia stato registrato, scritto, applicato...
 
Non so se ne avete gia' parlato piu' sopra.
 
Se non sbaglio dovrebbe esistere il comando 'kexec' che permette di
sostituire il kernel in uso con quello appena installato, non lo ho
mai usato e non conosco la sintassi del comando ma se funziona non
c'e' piu' necessita' di riavviare la macchina causa aggiornamento del
kernel.
-- 
Ciao
Andrea Malfatti