例えば。これは/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
しかし、誰がそれをしたかはわかりません。だれがそれをしたのか知りたい場合は、コードを追加する必要があります。これは、次回知っていることを意味します。
このリソースをオンラインで見つけました。それはあなたに役立つかもしれません:
あなたは2つのことを調べる必要があります:
これらの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'
このコマンドを実行して*、出力を以下の例と比較してください。
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)
最も興味深いログメッセージをフィルタリングする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
を使用して順序を逆にして、最後のイベントが最新から最新のイベントまで印刷されることで混乱しないようにします。
調査する可能性のあるいくつかのログファイル:(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にも同様のニーズがあり、基本的にはログに明確で明確なメッセージがないことを観察しましたが、これは少し意外です。
/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
これがログの明示的なメッセージです。
私は不器用な考えを持っていますが、おそらくそれはあなたのために機能します:コマンド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
はこれらの行を示していますが、それらは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)でログインし、ホストを起動するときにそのままにして、ターミナルに次の行を取得することもできます。
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.
シャットダウンのエイリアスをスクリプトに
スクリプトは、すべてのパラメーターなどを元のシャットダウン実行可能ファイルに与える必要があります
しかし、スクリプトはこれらをログに記録する必要があります