昨夜CentOS 6をアップデートしましたが、かなり大きなアップデートでした。ダウンロードを完了することを決定したとき、プロセスはダウンロードを完了するまでいくつかのパッケージしか残りませんでした。それで60分シャットダウンを予約して去りました。
今朝システムを確認してみるとシステムがダウンしていました。いくつかの問題が発生しました（予想していたものです）。ただログを見ると、yumログの終わりを更新するのに予想よりも時間がかかるようです。
これが見つかったときにyum updateを再実行しました。すべてが最新の状態です。もう一つの質問は、
すっきり仕上がりましたか？どうやって確認しますか？
答え1
時には機械が損傷することがあります。これは既知の問題です。
変更で修正されなければなりませんsystemd。 ~によると
CentOS 6が実行されていませんsystemd。したがって、コンピュータに問題がある可能性があります。
答え2
理想的には、等級（同じ更新を複数回実行すると、一度実行したのと同じ結果が得られます。）弾力のある（再起動で更新が中断された場合は、再起動後に更新を再開できます。）しかし、更新できません。原子（半分更新されたシステム状態）。
実際には、等級が機能します。中断された場合（エラー、+押す、スケジュールされた再起動、停電などyum updateのため）システムを再起動してから再度実行し、完了するまで待ちます。CtrlCyum 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代わりにこのような内容が表示されることがあります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.
systemd（CentOS 6にはメッセージはありませんが、関連内容が印刷されます。）
/etc/rsyslog.conf/shutdownの構成によっては/etc/syslog.conf記録されない場合がありますが、システムに障害が発生した場合は必ず記録される内容があります。したがって、検索は、stopped|shutいつ状況が悪化し始めるのかを確認するための良いヒューリスティックです。
yum2つのログのタイムスタンプを比較すると、システムがクラッシュする前に操作を完了したかどうかがわかります。