Perché l'aggiornamento di un sistema Linux in esecuzione non è problematico?

Sono anni che uso i sistemi Linux su base giornaliera e non ho mai avuto grossi problemi aggiornando un sistema mentre era in esecuzione, ma mi chiedo ancora perché questo sia possibile.

Lasciami fare un esempio.

Supponiamo che un programma "A" di un determinato pacchetto sia in esecuzione su un sistema. Questo programma, ad un certo punto, deve aprire un altro file ("B") dallo stesso pacchetto. Successivamente, il programma "A" chiude "B" perché non ne ha più bisogno. Supponiamo che ora aggiorni i pacchetti "A" e "B" a cui appartengono. "A" non è direttamente interessato da queste operazioni, almeno per il momento, poiché è in esecuzione nella RAM e l'aggiornamento ha appena sostituito "A" sul disco rigido. Supponiamo che "B" sia stata sostituita anche sul filesystem. Ora "A" deve leggere di nuovo "B" per qualche motivo. La domanda è: è possibile che "A" possa trovare una versione incompatibile di "B" e crash o malfunzionamento in qualche altro modo?

Perché nessuno aggiorna i propri sistemi riavviando con un CD live o una procedura simile?

L'aggiornamento di Userland è raramente un problema

Spesso puoi aggiornare i pacchetti su un sistema live perché:

1. Le librerie condivise sono archiviate in memoria, non lette dal disco ad ogni chiamata, quindi le vecchie versioni rimarranno in uso fino al riavvio dell'applicazione.
2. I file aperti vengono effettivamente letti dai descrittori di file , non dai nomi dei file, quindi i contenuti dei file rimangono disponibili per le applicazioni in esecuzione anche quando vengono spostati / rinominati / eliminati fino a quando i settori non vengono sovrascritti o i descrittori di file vengono chiusi.
3. I pacchetti che richiedono il ricaricamento o il riavvio sono generalmente gestiti correttamente dal gestore dei pacchetti se il pacchetto è stato ben progettato. Ad esempio, Debian riavvierà alcuni servizi ogni volta che libc6 viene aggiornato.

Generalmente, a meno che non stiate aggiornando il kernel e non stiate usando ksplice, potrebbe essere necessario riavviare programmi o servizi per sfruttare un aggiornamento. Tuttavia, raramente è necessario riavviare un sistema per aggiornare qualsiasi cosa in userland, sebbene sui desktop sia occasionalmente più facile che riavviare i singoli servizi.

Guarda anche

http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode

Sì, ciò che hai descritto è possibile, ma la maggior parte delle volte se il file è incluso nel pacchetto, sarà una libreria o un altro file che verrà letto una volta e una sola volta (poiché non cambia, non c'è motivo di leggilo più volte). Inoltre, se il file è necessario a lungo termine, l'applicazione probabilmente lascerà aperto l'handle del file, in cui anche se verrà sostituito sul file system effettivo, l'handle del file aperto manterrà aperta la vecchia versione.

Nella maggior parte dei casi, tutti i dati letti più volte durante la vita del processo sono dati utente / variabili e ciò non cambierebbe durante l'aggiornamento del pacchetto. Inoltre, poiché i dati sono variabili, qualsiasi programmatore nella loro mente corretta si assicurerebbe che il programma sia in grado di gestirlo cambiando da una lettura all'altra.

Supponiamo che "B" sia stata sostituita anche sul filesystem. Ora "A" deve leggere di nuovo "B" per qualche motivo. La domanda è: è possibile che "A" possa trovare una versione incompatibile di "B" e crash o malfunzionamento in qualche altro modo?

Questo è possibile, ma è improbabile nella maggior parte dei casi. Se "B" è una libreria di codici, la versione originale non verrebbe normalmente chiusa. "A" continuerà a utilizzare la versione originale di "B". Se si esegue "A" dopo l'aggiornamento, verrà utilizzata la nuova versione di "B". Durante l'aggiornamento, esiste il rischio che vengano caricate versioni incompatibili. Tuttavia, a causa del modo in cui vengono caricate le librerie di codici, questo dovrebbe essere un problema solo se "A" necessita di funzionalità non presenti nelle versioni di "B" caricate.

Le buone pratiche di codifica mantengono l'interfaccia allo stesso modo. Di conseguenza, non importa molto quale versione è caricata, a parte se ci fossero bug corretti nella versione più recente.

I file di configurazione sono leggermente diversi, ma di solito vengono letti all'avvio. In questo caso, "A" non legge "B" a meno che non venga modificato un ricaricamento della configurazione. Ancora una volta, sarebbe una cattiva pratica di codifica cambiare il formato o il significato del file di configurazione. Una versione incompatibile del file di configurazione dovrebbe avere un nome diverso, quindi non causerebbe un problema.

Perché nessuno aggiorna i propri sistemi riavviando con un CD live o una procedura simile?

L'arresto e il riavvio da una versione diversa porterebbe a un'interruzione del servizio. Per i server, questo non è generalmente desiderato. In ogni caso, il gestore pacchetti sul sistema in esecuzione è a conoscenza del software e delle versioni installate. I CD live hanno un proprio elenco di software installati, possibilmente con versioni diverse. Ciò rende difficile aggiornare in modo affidabile il sistema in esecuzione dal CD live.

I CD live vengono talvolta utilizzati quando viene installata una nuova versione dell'O / S. In questo caso, di solito viene eseguita un'installazione pulita dell'O / S. Ciò può limitare la quantità di file non utilizzati dalla versione precedente mantenuta. Può essere più impegnativo che aggiornare il sistema live. Tuttavia, se si utilizzano partizioni di root diverse, è possibile limitare il rischio di rimanere bloccati con un sistema parzialmente aggiornabile non avviabile.

Ci sono alcuni casi in cui questo è un problema:

• Aggiornamento di JDK mentre una java-VM è in esecuzione: ho posto a myselv la stessa domanda che hai fatto: avevo un tomcat in esecuzione che utilizza java. Ora, dopo un aggiornamento di patch del JDK, continuava a funzionare senza problemi, quindi sembrava.

Ora la spiegazione è cache-memory. OK - Ho avviato un programma di memoria per utilizzare tutta la RAM disponibile - e quindi Tomcat si è arrestato in modo anomalo (dopo aver eseguito l'accesso all'application).

• Aggiornamento del kernel su sistemi SuSE: Su SuSE il vecchio kernel e i suoi moduli vengono cancellati subito dopo l'aggiornamento della patch del kernel. Se poi vuoi usare qualcosa di nuovo, che richiede un modulo kernel, che non è stato caricato fino ad ora, il servizio fallirà.