Cosa succede effettivamente quando aggiorniamo linux?

Hai un sacco di domande! Cominciamo dall'inizio. Non state tanto "aggiornando Linux" quanto aggiornando "redhat" o "ubuntu" o qualsiasi altra cosa - state aggiornando la vostra distro, che è quasi certamente una "GNU/Linux distro".

Linux stesso - il kernel - è spesso impostato come un pacchetto tramite qualsiasi gestore di pacchetti che la vostra distro sta usando - quindi, in effetti, a volte quando ci sono aggiornamenti, saranno aggiornamenti al vostro kernel Linux, ma altre volte, ci saranno semplicemente aggiornamenti ad alcune delle centinaia di altri pacchetti che avete installato.

Quando il vostro gestore di pacchetti aggiorna i pacchetti del kernel, di solito non vedrete alcun effetto da questo fino al riavvio.

Dico "di solito" perché c'è una remota possibilità, se sei uno sviluppatore del kernel o stai codificando qualcosa che usa gli header del kernel, che le modifiche apportate ai pacchetti kernel-devel possano avere un impatto sulle tue compilazioni/test fin quando non hai riavviato il nuovo kernel.

Ma, per la maggior parte delle persone, questo non sarà un problema. Si può benissimo non riavviare subito dopo l'aggiornamento a un nuovo kernel. Quello vecchio e quello nuovo possono vivere fianco a fianco per un bel po' di tempo. Guarda nei dettagli di "grub" per maggiori informazioni su questo. Il tuo sistema probabilmente ha già almeno 2 o 3 versioni più vecchie del kernel, pronte ad avviarsi se quella attuale ti dà qualche problema.

Prossimo. Guardiamo gli aggiornamenti dei programmi regolari. Per esempio, qualcosa come "vim".

Per quelli, la nuova versione del programma sarà installata proprio sopra la vecchia versione. Qualsiasi processo attualmente in esecuzione continuerà a eseguire il vecchio eseguibile, anche se è stato cancellato. Una volta che il conteggio dei descrittori di file aperti su quel vecchio eseguibile raggiunge lo zero, sarà effettivamente cancellato. Fino ad allora, è ancora accessibile per quei processi che lo stanno ancora eseguendo. Da una shell di root eseguite "lsof|grep '(deleted)'" e vedrete che il vostro sistema potrebbe mostrare file cancellati che sono ancora aperti, proprio ora.

A volte, per i servizi (processi demone, in ascolto sulle porte) i "passi successivi all'installazione" per l'installazione di un pacchetto includeranno un riavvio del servizio, per assicurarsi che inizi ad eseguire automaticamente la nuova versione del pacchetto.

Questo viene fatto perché, a differenza di un normale programma che un utente smetterà di usare prima o poi, non c'è davvero nulla che esca dai vari servizi durante l'uso regolare, quindi questo passo di riavvio è una buona idea.

Gli aggiornamenti automatici dei linguaggi di programmazione, dei motori di database e dei servizi di sistema possono sicuramente causare problemi. Per esempio - le versioni più recenti di PHP hanno iniziato a deprecare certe funzioni - mi vengono in mente split() ereg() ed eregi().

Gli sviluppatori hanno pensato che sarebbe stata una buona idea inserire nel log degli errori degli avvisi di deprezzamento. Ancora e ancora e ancora e ancora e ancora e ancora.

Sfortunatamente, hanno impostato questi avvisi ad un livello di log che significa che vengono scritti in quasi tutti i log di errore a livello di produzione. Così, gli amministratori di sistema come me trovano regolarmente i server dei clienti a corto di spazio su disco senza alcuna ragione apparente.

I log degli errori, che il cliente ha smesso di guardare mesi o anni fa una volta che tutti i problemi iniziali sono stati risolti, all'improvviso iniziano a riempirsi di migliaia se non milioni di copie degli stessi identici avvisi di deprezzamento.

Un'altra cosa che può creare scompiglio è l'aggiornamento automatico dei server di database. C'è un repo linux francese che è famoso per, di punto in bianco, passare le versioni di MySQL all'ultima versione disponibile. Ottimo per gli sviluppatori - orribile per gli ambienti di produzione. I server sottoscritti a quel repo per gli aggiornamenti dei pacchetti si rompono tutti lo stesso giorno, con gli stessi strani errori, causati da qualsiasi incompatibilità/deprecazioni/cambiamenti di default arrivati con la nuova versione di MySQL.

La tua domanda finale era sulla stabilità dopo gli aggiornamenti, prima di un riavvio. La risposta è, "di solito no, ma dipende".

Dipende da quale distro stai usando, e a quali canali hai iscritto il tuo server.

Se stai usando Fedora - che'è bleeding edge. Aspettatevi instabilità dopo gli aggiornamenti dei pacchetti. Non tanto l'instabilità del "riavvio", quanto l'instabilità dovuta a possibili regressioni che potrebbero essersi insinuate, e l'instabilità dovuta a nuovi bug che potrebbero essere stati appena introdotti insieme a nuove funzionalità che sono state appena installate dagli aggiornamenti dei pacchetti.

Se state usando RedHat o Centos, iscritti a canali accuratamente controllati, non aspettatevi alcuna instabilità. Aspettatevi una consistenza solida come una roccia, senza bisogno di riavviare. Aspettatevi che un riavvio non aiuterebbe il problema se ne sperimentaste uno, perché il problema è probabilmente qualcosa che in qualche modo è sfuggito al processo di controllo che è stato fatto per i cambiamenti che sono stati introdotti. E, aspettatevi che molto probabilmente, non è stato l'aggiornamento del pacchetto a rompere le cose, ma qualcosa che voi o qualcun altro del vostro team ha fatto sul server che prima andava bene, ma che ora non va più bene per qualsiasi motivo.

RedHat è sufficientemente stabile che mi imbatto regolarmente in server che sono in funzione da oltre 2 anni e che stanno andando bene, senza bisogno di un riavvio. Questo è stabile! Leggete questo per maggiori dettagli su come RedHat fa quello che fa: https://access.redhat.com/security/updates/backporting/?sc_cid=3093

Ubuntu server è un'altra distro che'è estremamente attenta agli aggiornamenti dei pacchetti - controllandoli. Probabilmente ce ne sono altre di cui non sono a conoscenza.

Ci sono sicuramente molte distro Linux che sono rivolte più agli sviluppatori che agli ambienti di produzione - quindi con quelle, è necessario rivedere le liste dei pacchetti che vengono aggiornati automaticamente, e testare le cose di volta in volta, e correggere le cose che si sono rotte.

Ma siate consapevoli che la maggior parte delle volte, non sarà un riavvio a sistemare quelle cose una volta che si sono rotte - sarà introducendo le nuove direttive giuste in qualche file di configurazione, o rimuovendo quelle vecchie, o simili.

Se vi state chiedendo di cosa diavolo stavo parlando riguardo a quanto sopra, fatemelo sapere, e proverò a riformulare meglio le cose.