ログからシステムのシャットダウンの原因を見つける方法

たとえば、私はこれを見ています/var/log/messages：

Mar 01 23:12:34 hostname shutdown: shutting down for system halt

シャットダウンの原因を見つける方法はありますか？たとえば、コンソールから実行されたのか、誰かが電源ボタンを押すなどしたのですか？

システムを正常にシャットダウンできるのは、ルート特権プログラムのみです。そのため、システムが通常の方法でシャットダウンするときは、root権限を持つユーザーまたはacpiスクリプトのいずれかです。どちらの場合でも、ログを確認することで確認できます。ACPIシャットダウンは、電源ボタンの押下、過熱、またはバッテリー低下（ラップトップ）によって発生する可能性があります。3つ目の理由である、電源が落ちたときにUPSソフトウェアを忘れてしまいました。

最近、システムの電源が異常にオフになり、オーバーヒートし、moboが電源がオフになるように設定されていることが判明しました。システムにはログを保存する機会がありませんでしたが、幸いなことにシステムの温度を監視すると、電源を切る直前にシステムの温度が上昇し始めていることがわかりました。

したがって、通常のシャットダウンの場合はログに記録され、侵入の場合は幸運です。コールドシャットダウンの場合は、環境を制御および監視するのが最善の方法です。

次のコマンドを試してください。

最後の再起動エントリのリストを表示します。 last reboot | less

最後のシャットダウンエントリのリストを表示します。 last -x | less

より正確には： last -x | grep shutdown | less

ただし、誰がそれを行ったかはわかりません。誰がそれをしたかを知りたい場合は、コードを少し追加する必要があります。これは、次回からわかることを意味します。

このリソースはオンラインで見つけました。あなたに役立つかもしれません：

誰が、または何が私のシステムを止めたのかを知る方法

確認することがいくつかあります。

最後の-xコマンドの出力を確認します

このコマンド*を実行し、出力を以下の例と比較します：

last -x | head | tac

通常のシャットダウンの例

通常のシャットダウンと電源投入は次のようになります（シャットダウンイベントがあり、次にシステムブートイベントがあることに注意してください）。

runlevel (to lvl 0)   2.6.32- Sat Mar 17 08:48 - 08:51  (00:02) 
shutdown system down  ... <-- first the system shuts down   
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 3)       

場合によっては、これが表示されることがあります（シャットダウンに関する行はありませんが、システムは「停止状態」であるランレベル0でした）。

runlevel (to lvl 0)   ... <-- first the system shuts down (init level 0)
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 2)   2.6.24-... Fri Aug 10 15:58 - 15:32 (2+23:34)   

予期しないシャットダウンの例

停電による予期しないシャットダウンは次のようになります（以前のシステムシャットダウンイベントのないシステムブートイベントがあることに注意してください）。

runlevel (to lvl 3)   ... <-- the system was running since this momemnt
reboot   system boot  ... <-- then we've a boot WITHOUT a prior shutdown
runlevel (to lvl 3)   3.10.0-693.21.1. Sun Jun 17 15:40 - 09:51  (18:11)    

/ var / logのログを調べます

最も興味深いログメッセージをフィルタリングするbashコマンドは次のとおりです。

grep -iv ': starting\|kernel: .*: Power Button\|watching system buttons\|Stopped Cleaning Up\|Started Crash recovery kernel' \
  /var/log/messages /var/log/syslog /var/log/apcupsd* \
  | grep -iw 'recover[a-z]*\|power[a-z]*\|shut[a-z ]*down\|rsyslogd\|ups'

予期しない電源オフまたはハードウェア障害が発生した場合、ファイルシステムは適切にアンマウントされないため、次の起動時に次のようなログが記録される場合があります。

EXT4-fs ... INFO: recovery required ... 
Starting XFS recovery filesystem ...
systemd-fsck: ... recovering journal
systemd-journald: File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.

ユーザーが電源ボタンを押したためにシステムの電源が切れると、次のようなログが記録されます。

systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.

システムが正常にシャットダウンした場合にのみ、次のようなログを取得します。

rsyslogd: ... exiting on signal 15

過熱によりシステムがシャットダウンすると、次のようなログが記録されます。

critical temperature reached...,shutting down

UPSがあり、電源とシャットダウンを監視するデーモンを実行している場合は、明らかにそのログを確認する必要があります（/ var / log / messagesのNUTログが/ var / log / apcupsd *のapcupsdログ）

ノート

*：以下にlast、そのmanページの説明を示します。

last [...] prints information about connect times of users. 
Records are printed from most recent to least recent.  
[...]
The special users reboot and shutdown log in when the system reboots
or (surprise) shuts down. 

私たちは、使用head、最新の10回のイベントを保つために、我々は使用tac直近から少なくとも最近のイベントを最後にプリントすることを、我々は事実によって混乱しないように順序を反転させます。

調査可能ないくつかのログファイル：（Ubuntuシステムが見つかりましたが、ほとんどのLinux / Unixシステムに存在することを望みます）

/var/log/debug
/var/log/syslog (will be pretty full and may be harder to browse)
/var/log/user.log
/var/log/kern.log
/var/log/boot

繰り返しますが、これらのログファイルはUbuntuシステムに存在するため、ファイル名が異なる場合があります。tailコマンドはあなたの友達です。

使用して簡素化するlast上でのシステムのシャットダウン及びランレベルの変更やフィルタリングを表示するshutdownとreboot：

last -x shutdown reboot

完全に満足していない

Debian 7.8でも同様のニーズがあり、基本的にログには明確で明示的なメッセージがないことに気付きました。これは少し驚くべきことです。

Grep through /var/logは、マシンがシャットダウンされた時間、適切なデーモンのシャットダウンなどを示しますが、最初の理由は示しません。

shutdown[25861]: shutting down for system halt

上記の他のソリューション（last -x）はあまり役に立ちませんでした。

仕組みを調べる

次/etc/acpi/powerbtn-acpi-support.shを含む読書：

if [-x /etc/acpi/powerbtn.sh]; それから
    ＃acpidパッケージの古い構成スクリプトとの互換性
    /etc/acpi/powerbtn.sh
elif [-x /etc/acpi/powerbtn.sh.dpkg-bak]; それから
        ＃acpidパッケージの古い構成スクリプトとの互換性
    ＃管理者によって変更されたため、まだ使用されています
        /etc/acpi/powerbtn.sh.dpkg-bak
他に
    ＃通常の取り扱い。
    / sbin / shutdown -h -P now "電源ボタンが押されました"
fi

shutdownコマンドのパラメーターとして明示的なテキストが指定されていることに注意してください。この文字列は、シャットダウンプログラムによって自動的にログに記録されると予想されます。

より良いログのための調整

とにかく、明示的なメッセージを取得するには、新しく作成し/etc/acpi/powerbtn.shた実行可能ファイルに以下のテキストを（ルートとして）入れますchmod a+x /etc/acpi/powerbtn.sh

＃！/ bin / sh
/etc/acpi/powerbtn.shのロガー、おそらく「電源ボタンが押された」
    / sbin / shutdown -h -P now "電源ボタンが押されました"

この方法で実行すると、おそらく変更よりも長続きする変更が行われ/etc/acpi/powerbtn-acpi-support.shます。後者のオプションは、おそらくパッケージの次のアップグレードでその効果を失いますacpi-support-base。

Ubuntu 14.04とは異なる方法で通知さ/etc/acpi/powerbtn.shれacpidます（パッケージとは異なるコンテンツで既に存在します）。また、Debian 8はおそらく異なる方法でそれを行います。バリエーションを提供してください。

利益！

電源ボタンが押されたときに、今、以下のような行がで表示され/var/log/messages、/var/log/syslogそして/var/log/user.log：

logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed

これは、ログ内の明示的なメッセージです。

私は不器用なアイデアを持っていますが、それはあなたのために働くかもしれません：コマンドlastを入力し、すべてのユーザーのログイン情報をチェックアウトします。次に、haltその時点でログインしていたために必要な権限を持つユーザーをフィルターします。次に、.bash_historyファイルをチェックして、停止に入ったかどうかを確認します。

私の場合、過熱の問題があり、/ var / logフォルダーの 'grep shut *'によって/ var / log / syslogにログが見つかりました。

記録されたエラーはこれでした：

Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down

私のKVM VM（ホストの再起動がゲストのクリーンシャットダウンを実行したかどうか疑問に思った場所）にそれを挿入する/var/log/auth.logだけlast -x shutdownで、（同じものを表示することに加えて）必要なものが見つかりました。そこで次の行が表示されました。

Sep  3 23:56:31 Web systemd-logind[531]: Power key pressed.
Sep  3 23:56:31 Web systemd-logind[531]: Powering Off...
Sep  3 23:56:31 Web systemd-logind[531]: System is powering down.
Sep  3 23:55:45 Web systemd-logind[591]: New seat seat0.
Sep  3 23:55:45 Web systemd-logind[591]: Watching system buttons on /dev/input/event0 (Power Button)
Sep  3 23:55:54 Web sshd[805]: Server listening on 0.0.0.0 port 22.
Sep  3 23:55:54 Web sshd[805]: Server listening on :: port 22.

last -xこれらの行が表示されますが、それらは最も最近の順序で印刷されていることに注意してください（つまり、最後の行を最初に読んでから上に移動します）が、クロックリセット（ブート前23:56、後23:55）のため前の行でも明らかなように、順序は少し戸惑っているようです。

runlevel (to lvl 2)   3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
reboot   system boot  3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
shutdown system down  3.13.0-123-gener Sun Sep  3 23:56 - 23:55  (00:00)    
runlevel (to lvl 0)   3.13.0-123-gener Sun Sep  3 23:56 - 23:56  (00:00)

私の側では、ホストの起動時にゲストが正常にシャットダウンすることを確認し、ゲストの1人にログイン（ssh）し、ホストの起動時にそこにとどまり、ターミナルで次の行を取得することもできます。

root@Web:~#
Broadcast message from root@Web
        (unknown) at 22:25 ...

The system is going down for power off NOW!
Connection to web closed by remote host.
Connection to web closed.

スクリプトにシャットダウン別名
スクリプトは、元のシャットダウン実行可能ファイルへのすべてのパラメータなどを与える必要があります
しかし：スクリプトはこのそれらをログインする必要があります

cat /usr/adm/syslog

私の場合、それはサーバーをシャットダウンするUPSソフトウェアでした。

/etc/rc.d/7/upsd.boot