it-swarm-ja.com

システムのシャットダウンの原因をログから確認するにはどうすればよいですか?

例えば。これは/var/log/messages

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

シャットダウンの原因を特定する方法はありますか?例えば。それはコンソールから実行されましたか、それとも誰かが電源ボタンなどを押しましたか?

123
alex

システムを正常にシャットダウンできるのは、ルート特権プログラムだけです。したがって、システムが通常の方法でシャットダウンする場合、それはroot特権を持つユーザーかacpiスクリプトのいずれかです。どちらの場合も、ログを確認することで確認できます。 ACPIシャットダウンは、電源ボタンを押す、過熱する、またはバッテリー残量が少ない(ラップトップ)ことが原因で発生する可能性があります。 3番目の理由、電源が故障したときにUPSソフトウェアが忘れてしまい、とにかくアラートが送信されてしまいました。

最近、システムの電源を何度も切ったところ、異常に電源が切れるようになりました。システムが過熱していて、moboがすぐに電源を切るように設定されていました。システムはログを保存する機会がありませんでしたが、幸い、システムの温度を監視すると、電源を切る直前にシステムの温度が上昇し始めていることがわかりました。

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

50
forcefsck

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

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

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

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

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

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

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

127

あなたは2つのことを調べる必要があります:

  1. last -xコマンドの出力
  2. / var/log /のログファイル

これらの2つのコマンドを使用して、詳細を確認してください。

last -x | head | tac

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'

1)最後の-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)    

2)/ 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があり、デーモンを実行して電源とシャットダウンを監視している場合は、そのログを確認する必要があります(NUTは/ var/log/messagesに記録しますが、apcupsdは/ var/log/apcupsd *に記録します)。


メモ

*:マニュアルページのlastの説明は次のとおりです。

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を使用して順序を逆にして、最後のイベントが最新から最新のイベントまで印刷されることで混乱しないようにします。

26
ndemou

調査する可能性のあるいくつかのログファイル:(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コマンドはあなたの友達です。

11
user6148

lastを使用して、システムシャットダウンエントリと実行レベルの変更を表示し、shutdownrebootをフィルタリングして簡略化します。

last -x shutdown reboot
8
jhvaras

十分に満足していない

私はDebian 7.8にも同様のニーズがあり、基本的にはログに明確で明確なメッセージがないことを観察しましたが、これは少し意外です。

/var/logを介してGrepを実行すると、マシンがシャットダウンされた時刻、適切なデーモンのシャットダウンなどが表示されますが、初期の理由はわかりません。

shutdown[25861]: shutting down for system halt

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

仕組みを見る

以下を含む/etc/acpi/powerbtn-acpi-support.shの読み取り:

 if [-x /etc/acpi/powerbtn.sh]; then 
#acpidパッケージの古い構成スクリプトとの互換性
 /etc/acpi/powerbtn.sh
Elif [-x /etc/acpi/powerbtn.sh.dpkg-bak] ; then 
#acpidパッケージからの古い設定スクリプトとの互換性
#管理者によって変更されたため、まだ存在しています
 /etc/acpi/powerbtn.sh.dpkg-bak 
 else 
#通常の処理。
/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の場合とは異なります(acpidパッケージとは異なるコンテンツで/etc/acpi/powerbtn.shがすでに存在しています)。また、Debian 8はおそらく異なる方法で実行します。バリエーションを自由に提供してください。

利益!

電源ボタンを押すと、/var/log/messages/var/log/syslog/var/log/user.logに次のような行が表示されます。

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

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

8

私は不器用な考えを持っていますが、おそらくそれはあなたのために機能します:コマンドlastを入力し、すべてのユーザーのログイン情報を確認してください。次に、その時点でログインしていたhaltに必要な権限を持つユーザーをフィルタリングします。次に、.bash_historyファイルを使用して、停止に入ったかどうかを確認します。

4
sazary

私の場合、過熱の問題があり、/ 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
1
luandrea

私の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はこれらの行を示していますが、それらはmost-recent-firstの順序で出力されていることに注意してください(つまり、最後の行を最初に読み取ってから上に移動します)。ただし、クロックリセット(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)でログインし、ホストを起動するときにそのままにして、ターミナルに次の行を取得することもできます。

[email protected]:~#
Broadcast message from [email protected]
        (unknown) at 22:25 ...

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

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

0
LanceBaynes