Linuxシステムとカーネル1976年4月14日最後にutil-linuxで2.35.1。
last -x reboot shutdown突然のシャットダウンと停電を検出するために使用します。私が理解したのは、クリーンリブートがペアで表示されることです。閉鎖そして再起動wtmpのエントリです。これはたとえばサポートされます。この記事。徹底的なシーケンスにより、異常終了または停電を推論できます。再起動入場はありません閉鎖間。
しかし、常にそうではないことがわかりました。閉鎖遭遇したときsystemctl reboot- 注文がよく見えます。再起動エントリとユーザーセッションは次のようにリストされます。衝突。ただし、時にはログを終了してエントリを再起動することがあります。
systemctl reboot例：4回実行しました。
$ last -x reboot shutdown
reboot system boot 4.14.76-6.1.0-so Wed Aug 31 13:12 still running
shutdown system down 4.14.76-6.1.0-so Wed Aug 31 13:12 - 13:12 (00:00)
reboot system boot 4.14.76-6.1.0-so Wed Aug 31 12:56 - 13:12 (00:15)
reboot system boot 4.14.76-6.1.0-so Wed Aug 31 11:24 - 13:12 (01:47)
reboot system boot 4.14.76-6.1.0-so Wed Aug 31 11:23 - 13:12 (01:48)
shutdown system down 4.14.76-6.1.0-so Wed Aug 31 11:22 - 11:23 (00:00)
この問題を直接解決する質問を1つだけ見つけましたが、残念ながらRHEL サブスクリプションの後ろにロックされています。。
デュアルブートに従わなかった。これは別のSE質問です、それ自体が不一致の例である可能性があります。閉鎖ログイン
systemctl再起動が一貫して記録されない理由を知っている人はいますか？閉鎖横に再起動？
システムに予期しない再起動/停電が発生したかどうかを確実に知るためのより良い方法はありますか？
ベストアンサー1
私の答えはこの間違ったチケットsystemdデバイスの依存関係が原因でutmpアップデートサービスが終了すると、実行は失敗します。
最後のログRequisite=ディレクティブを空白に設定することで、systemd-update-utmp-runlevel.service確実に取得できます。閉鎖クリーン再起動のためのアイテムです。