☰

如果我安排在更新过程中关闭会发生什么情况？

tag-icon • tag-icon centos yum shutdown
如果我安排在更新过程中关闭会发生什么情况？

我昨晚更新了 CentOS 6，更新量相当大。当我决定让它完成时，该过程距离完成下载只剩下几个包了。因此，我安排了 60 分钟的关机时间然后离开。

今天早上我检查系统时，它已经关闭了。我遇到了一些麻烦（我预料到了一些事情），只是，当我查看日志时，我注意到 yum 日志的末尾似乎更新时间比我预期的要长。

当我注意到这一点时，我重新运行 yum update。一切都是最新的。另一个问题是，

干干净净完成了吗？我该如何检查？

答案1

有时它会损坏你的机器。这是一个已知问题：

并且应该已通过更改来修复systemd。根据

CentOS 6 未运行systemd。所以问题可能存在于你的机器上。

答案2

理想情况下，更新是幂等（如果多次运行相同的更新，您将获得与运行一次相同的结果）并且有弹性的（如果更新因重启而中断，您可以在重启后恢复更新）。但更新不是原子（有一半更新的系统状态）。

在实践中，幂等性确实有效。如果yum update中断（由于错误、按Ctrl+ C、计划重新启动、电源故障等），只需yum update在系统重新启动后再次运行，并等待其完成。

在实践中，韧性通常有效。软件包管理器会先将新版本的文件解压到临时名称下，然后用新文件替换旧文件。如果更新在最长的阶段（解压，需要大量磁盘写入）中断，系统状态不会发生重大变化，因此不会造成任何损害。如果更新在替换阶段中断，事情会变得更加复杂。正在更新的软件可能会由于不同文件之间的版本不匹配而无法使用。

大多数关键软件包可以逐个文件进行更新，或者具有按适当顺序执行的配置步骤，以确保系统保持运行。例如，rpm由单个二进制文件组成，因此您要么获得旧的二进制文件，要么获得新的二进制文件。内核也是如此。然而，由于有数千个包、数十万个文件以及文件系统级别写入重新排序的巨大潜力，组合数学非常非常高，并且不可能测试所有内容。因此，如果在更新过程中被中断，系统可能无法正常启动。但这种可能性非常小（当然，除非有错误）。

答案3

在 CentOS 上，该文件/var/log/yum.log应包含最后一个软件包升级的时间。例如在我的 CentOS 上（我的当前运行的是 CentOS 7，但文件位于同一位置）：

# 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

yum update（是的，我有一段时间没有跑步了）

然后，您可以将其与messages有关关闭的系统日志进行比较。 Syslog 会轮换日志，因此您可能会看到类似的内容messages-20160807而不是 plain messages，也请检查一下。例如：

# 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.

（CentOS 6 不会有systemd消息，但会打印相关内容。）

/etc/rsyslog.conf根据/ shutdown中的配置，/etc/syslog.conf可能不会记录，但当系统出现故障时，肯定会记录一些内容。因此，搜索stopped|shut是一种很好的启发式方法，可以检查事情何时开始恶化。

比较两个日志中的时间戳，您可以很好地了解yum系统是否在系统崩溃之前完成了工作。

相关内容