O que aconteceria se eu agendasse um desligamento no meio de uma atualização?

Question

Eu fiz uma atualização do CentOS 6 na noite passada, que era bem grande. No momento em que decidi deixá-lo para terminar, o processo foi apenas alguns pacotes longe de completar o download. Então, agendei um desligamento por +60 minutos e saí.

Quando eu chequei no sistema esta manhã, o desligamento foi interrompido. Eu estou tendo alguns problemas (eu esperava algo), apenas, enquanto eu estava olhando para logs, notei que o fim do log do yum parece que a atualização demorou mais do que eu esperava.

Quando notei isso, eu reran yum update. Tudo está atualizado. Outra questão é,

Terminou de forma limpa. Como posso verificar?

    

Answer 1

No CentOS, o arquivo /var/log/yum.log terá o tempo que o último pacote foi atualizado. Por exemplo, no meu CentOS (o meu está atualmente rodando o CentOS 7, mas o arquivo está no mesmo lugar):

# tail -n 3 /var/log/yum.log
Jun 28 17:10:04 Updated: 1:mariadb-libs-5.5.47-1.el7_2.x86_64
Jun 28 17:10:05 Updated: graphite2-1.3.6-1.el7_2.x86_64
Jun 28 17:10:05 Updated: zsh-5.0.2-14.el7_2.2.x86_64

(Sim, eu não corri yum update por algum tempo)

Você pode comparar isso com o syslog messages sobre o desligamento. O syslog rotaciona os logs, então você pode ter algo como messages-20160807 em vez de messages , verifique isso também. Por exemplo:

# egrep -i 'stopped|shut' /var/log/messages*
/var/log/messages-20160731:Jul 24 23:55:55 orion systemd: Stopped target Multi-User System.
/var/log/messages-20160731:Jul 24 23:55:55 orion systemd: Stopped Resets System Activity Logs.
/var/log/messages-20160731:Jul 24 23:55:57 orion systemd: Stopped Permit User Sessions.
/var/log/messages-20160731:Jul 24 23:55:57 orion systemd: Stopped target Remote File Systems.
/var/log/messages-20160731:Jul 24 23:56:33 orion systemd[1]: Listening on Delayed Shutdown Socket.
/var/log/messages-20160731:Jul 24 23:56:33 orion systemd[1]: Starting Delayed Shutdown Socket.

(o CentOS 6 não terá systemd mensagens, mas algo relevante será impresso.)

Dependendo da configuração em /etc/rsyslog.conf / /etc/syslog.conf , o desligamento pode não ser registrado, mas algo certamente é registrado quando o sistema fica inativo. Portanto, pesquisar por stopped|shut é uma boa heurística para verificar quando as coisas começaram a diminuir.

Comparando os registros de data e hora em ambos os registros, você pode ter uma boa noção se yum terminou seu trabalho antes que o sistema caísse.

    

Answer 2

Ocasionalmente, ele irá quebrar sua máquina. Tem sido um problema conhecido:

• Bug 755335: Encerrando enquanto a atualização automática quebra o sistema

e supostamente foi corrigido por uma alteração em systemd . De acordo com

• Como para descobrir se um sistema usa SysV, Upstart ou Systemd no seu sistema

O CentOS 6 não está executando systemd . Então, o problema pode existir em sua máquina.

    

Answer 3

Idealmente, as atualizações são idempotentes (se você executar a mesma atualização várias vezes, você obtém o mesmo resultado como se tivesse executado uma vez) e resiliente (se uma atualização é interrompida por uma reinicialização, você pode retomar o udpate após a reinicialização). Mas as atualizações não são atômicas (há estados do sistema semicualizados).

Na prática, a idempotência realmente funciona. Se yum update for interrompido (por um erro, pressionando Ctrl + C , por uma reinicialização agendada, por uma falha de energia,…), apenas execute yum update novamente depois que o sistema for reiniciado e aguarde a conclusão.

Na prática, a resiliência geralmente funciona. O gerenciador de pacotes toma o cuidado de primeiro descompactar os arquivos da nova versão com um nome temporário e, em seguida, substituir os arquivos antigos pelo novo. Se a atualização for interrompida durante a fase mais longa (a descompactação, que exige muitas gravações em disco), o estado do sistema não muda significativamente, portanto, nenhum dano é feito. Se a atualização for interrompida durante a fase de substituição, as coisas ficam mais complicadas. O software que está sendo atualizado pode ficar inutilizável devido a uma incompatibilidade de versão entre seus diferentes arquivos.

A maioria dos pacotes críticos pode ser atualizada arquivo por arquivo ou ter etapas de configuração executadas na ordem apropriada para garantir que o sistema permaneça operacional. Por exemplo, rpm consiste em um único binário, então você obtém o antigo ou o novo. Mesma coisa com o kernel. No entanto, com milhares de pacotes, centenas de milhares de arquivos e um grande potencial de reordenação de gravação no nível do sistema de arquivos, a combinatória é muito, muito alta, e é impossível testar tudo. Então, é possível acabar com um sistema que não inicializa de maneira limpa se foi interrompido no meio de uma atualização. Mas a probabilidade é muito pequena (exceto os bugs, é claro).