Por que atualizar um sistema Linux em execução não é problemático?

Question

São anos que eu uso sistemas Linux diariamente, e nunca tive grandes problemas ao atualizar um sistema quando estava em execução, mas ainda me pergunto por que isso é possível.

Deixe-me fazer um exemplo.

Suponha que um programa "A" de um determinado pacote esteja sendo executado em um sistema. Este programa, em um certo ponto, precisa abrir outro arquivo ("B") do mesmo pacote. Depois disso, o programa "A" fecha "B" porque não precisa mais dele. Suponha agora que eu atualizo o pacote "A" e "B" pertencem a. "A" não é diretamente afetado por essas operações, pelo menos por enquanto, já que está sendo executado na RAM e a atualização apenas substituiu "A" no disco rígido. Suponha que "B" tenha sido substituído no sistema de arquivos também. Agora "A" precisa ler "B" novamente por algum motivo. A questão é: é possível que "A" encontrasse uma versão incompatível de "B" e falhasse ou funcionasse de alguma outra forma?

Por que ninguém atualiza seus sistemas reiniciando com um live CD ou algum procedimento semelhante?

    

Answer 1

Atualizar Userland é raramente um problema

Você pode atualizar pacotes frequentemente em um sistema ativo porque:

1. Bibliotecas compartilhadas são armazenadas na memória, não lidas do disco em cada chamada, portanto, as versões antigas permanecerão em uso até que o aplicativo seja reiniciado.
2. Os arquivos abertos são lidos de descritores de arquivos , não dos nomes dos arquivos, portanto, o conteúdo do arquivo permanece disponível para o arquivo. executando aplicativos mesmo quando movidos / renomeados / excluídos até que os setores sejam sobrescritos ou os descritores de arquivos estejam fechados.
3. Os pacotes que exigem recarregamento ou reinicialização geralmente são tratados corretamente pelo gerenciador de pacotes se o pacote tiver sido bem projetado. Por exemplo, o Debian irá reiniciar certos serviços sempre que a libc6 for atualizada.

Geralmente, a menos que você esteja atualizando seu kernel e não esteja usando o ksplice, então os programas ou serviços podem precisar ser reiniciados para aproveitar uma atualização. No entanto, raramente há necessidade de reinicializar um sistema para atualizar qualquer coisa na userland, embora em desktops seja ocasionalmente mais fácil do que reiniciar serviços individuais.

Veja também

link

    

Answer 2

Sim, o que você descreveu é possível, mas na maioria das vezes, se o arquivo estiver incluído no pacote, será uma biblioteca ou outro arquivo que é lido uma vez e somente uma vez (já que não muda, há não há razão para lê-lo várias vezes). Além disso, se o arquivo for necessário a longo prazo, o aplicativo provavelmente deixará o identificador de arquivo aberto, no qual, mesmo que ele seja substituído no sistema de arquivos real, o identificador de arquivo aberto manterá a versão antiga aberta.

Na maioria dos casos, todos os dados que são lidos várias vezes durante a vida do processo são dados do usuário / variável, e isso não mudaria durante uma atualização de pacote. Além disso, como os dados são variáveis, qualquer programador no seu perfeito juízo se certificaria de que o programa pudesse manipulá-lo, mudando de uma leitura para a próxima.

    

Answer 3

Suppose "B" has been replaced on the filesystem, too. Now "A" needs to read "B" again for some reason. The question is: is it possible that "A" could find an incompatible version of "B" and crash or malfunction in some other way?

Isso é possível, mas improvável na maioria dos casos. Se "B" for uma biblioteca de códigos, a versão original normalmente não será fechada. "A" continuaria usando a versão original de "B". Se você executar "A" após a atualização, a nova versão de "B" será usada. Durante a atualização, há algum risco de que versões incompatíveis possam ser carregadas. No entanto, devido ao modo como as bibliotecas de código são carregadas, isso só deve ser um problema se "A" precisar da funcionalidade não presente nas versões de "B" que ele carregou.

Uma boa prática de codificação mantém a interface com as mesmas funções. Como resultado, não importa muito qual versão é carregada, exceto se houver erros corrigidos na versão mais recente.

Os arquivos de configuração são um assunto um pouco diferente, mas geralmente são lidos durante a inicialização. Nesse caso, "A" não seria "B" a menos que um recarregamento da configuração fosse alterado. Novamente, seria uma prática de codificação incorreta alterar o formato ou o significado do arquivo de configuração. Uma versão incompatível do arquivo de configuração deve ter um nome diferente, portanto, isso não causaria problemas.

Why nobody update their systems by rebooting with a live CD or some similar procedure?

Desligar e reinicializar a partir de uma versão diferente levaria a uma interrupção do serviço. Para servidores, isso geralmente não é desejado. Em qualquer caso, o gerenciador de pacotes no sistema em execução está ciente do software e das versões que instalou. Live CDs tem sua própria lista de softwares instalados, possivelmente com diferentes versões. Isso dificulta a atualização confiável do sistema em execução a partir do live CD.

Os CDs ao vivo às vezes são usados quando uma nova versão do O / S está sendo instalada. Nesse caso, a instalação limpa do O / S geralmente é feita. Isso pode limitar a quantidade de arquivos não usados da versão anterior a serem retidos. Pode ser mais esforço do que atualizar o sistema ao vivo. No entanto, se forem usadas partições-raiz diferentes, isso pode limitar o risco de ficar preso a um sistema parcialmente inicializável não-inicializável.

    

Answer 4

Existem alguns casos em que isso é um problema:

• Atualização do JDK enquanto um java-VM está em execução: Eu perguntei myselv a mesma pergunta que você tem - eu tinha um gato em execução que usa java. Agora, após uma atualização de patch do JDK, ele ainda funcionava sem problemas - assim parecia.

Agora a explicação é a memória cache. OK - Eu iniciei um programa de memória para usar toda a RAM disponível - e o tomcat falhou (depois que acessei o aplicativo em execução).

• Atualização de kernel em sistemas SuSE: No SuSE, o kernel antigo e seus módulos são excluídos logo após o patch-upgrade do kernel. Se você quiser usar algo novo, que requer um módulo do kernel, que não foi carregado até agora, o serviço falhará.