eqc_1101
2023年3月23日 10時55分
いつもお世話になっております。
Armadillo-IoT G3L にてハードウェアウォッチドッグの使用を行っており、
/dev/watchdogへのアクセスでタイムアウトによるリブートが発生することまでは確認できました。
⇒「echo > /dev/watchdog」をコマンド実行後、何もしないと10秒後リブート
⇒「echo > /dev/watchdog」をコマンド実行後、10秒以内に定周期でコマンド実行するとリブートされない
今検討しているのは、ユーザーアプリケーションでも別途リブートする処理を実装しているため、
再起動の要因を判別したく考えております。
①ユーザーアプリケーションによる再起動
②ハードウェアウォッチドッグタイマーによる再起動
①については、作成するユーザーアプリケーションにて判断できるため問題ないのですが、
②についてはどう判断すべきか分かりません。
自前で、①以外の場合は②と判断する、といった方法以外に、何か方法があればご教授頂けると幸いです。
（可能であれば、カーネルコンフィグレーション変更やカーネルコード変更等、
カーネルビルドによるインストールディスクの再作成を伴わない方法が望ましいです。（遠隔地のArmadillo更新があるため）
例：再起動後、あるファイルを見れば分かる／あるコマンドを実行すれば分かる等）
使用環境（他に必要があればご指示ください）：
Linux 4.9.133-at25
参考フォーラム：
https://armadillo.atmark-techno.com/forum/armadillo/4228
（似た問い合わせでしたが、製品がArmadillo-800シリーズだったため異なるかなと思っております）
よろしくお願いします。
コメント
eqc_1101
回答ありがとうございます。
アプリケーションでリセット前にログを残す方向で考えたとして、追加で確認させてください。
①
ハードウェアウォッチドッグタイマーのタイムアウトを事前に検出するのは
難しいのではと考えましたが、過去事例でもよいので何か案がございましたらご教示願います。
②
①が難しい場合、カーネルコンフィグレーション変更必須の認識ですが、
ソフトウェアウォッチドッグタイマーであれば再起動要因の特定は可能でしょうか？
（例えばご教示いただいたi2cgetのようなコマンドで再起動後に判別可能、等）
③
②も不可であるならば、ソフトウェアウォッチドッグタイマーであれば
リセット前にログを残すことは可能でしょうか？
例えば参考フォーラムには別製品ですがカーネルソース（？）にログ出力を
追記することで判別可能になるのでは、といった記述がありました。
①で解決できるのがよいと考えますが、②③についても
ご確認いただけますと幸いです。
よろしくお願いします。
at_mizo
溝渕です。
> ①
> ハードウェアウォッチドッグタイマーのタイムアウトを事前に検出するのは
> 難しいのではと考えましたが、過去事例でもよいので何か案がございましたらご教示願います。
ハードウェアウォッチドッグタイマーがタイムアウトするという事は、ソフトウェアが正常に動作していないという事です。その為、(正常に動作していない)ソフトウェアでタイムアウトを検出するのは厳しいと思います。
> ②
> ①が難しい場合、カーネルコンフィグレーション変更必須の認識ですが、
> ソフトウェアウォッチドッグタイマーであれば再起動要因の特定は可能でしょうか？
> （例えばご教示いただいたi2cgetのようなコマンドで再起動後に判別可能、等）
再起動要因は何が挙げられますか?
また、Linux起動パラメータに、
"soft_noboot=1"
を追加すると、ソフトウェアウォッチドッグタイマーがタイムアウトしても再起動しないようになります。このときにログを残して再起動する等で判別できませんか?
> ③
> ②も不可であるならば、ソフトウェアウォッチドッグタイマーであれば
> リセット前にログを残すことは可能でしょうか？
> 例えば参考フォーラムには別製品ですがカーネルソース（？）にログ出力を
> 追記することで判別可能になるのでは、といった記述がありました。
ソフトウェアウォッチドッグタイマーで再起動した場合、以下のようなログが出力されると思いますが、
https://armadillo.atmark-techno.com/blog/53/1319
再起動後に/var/log/等からこのログを確認できますか?
eqc_1101
①：
＞ハードウェアウォッチドッグタイマーがタイムアウトするという事は、ソフトウェアが正常に動作していないという事です。
＞その為、(正常に動作していない)ソフトウェアでタイムアウトを検出するのは厳しいと思います。
承知しました、同様の認識です。
②：
＞再起動要因は何が挙げられますか?
ユーザーアプリケーションが正常動作しなくなったことを
ソフトウェアウォッチドッグで監視して再起動したく。
ユーザーアプリケーション内でソフトウェアウォッチドッグ（/dev/watchdogX）を
定周期で書き込みます。そのため、書き込まれない⇒異常状態⇒再起動、の考えです。
③：
ご案内ありがとうございます。
出力されるログは、
「SoftDog: Initiating system reboot.」
の１行の認識で相違ないでしょうか？
また、出力ファイルはsyslogでしょうか、kern.logでしょうか？
よろしくお願いします。
at_mizo
eqc_1101
言葉足らず、失礼いたしました。
意図はソフトウェアウォッチドッグタイマーにより再起動されたのかを確認したいためです。
（ユーザーアプリケーション停止した場合の再起動、これの動作試験の結果を確認したい）
前段のやり取りで、ハードウェアウォッチドッグタイマーの場合は、
ログ出力もされず、起動後のコマンド等でも判断できない回答だったので、
ウォッチドッグタイマーによる再起動判別ができないと判断しました。
では、ソフトウェアウォッチドッグタイマーなら可能なのか、といった質問です。
結論、ソフトウェアウォッチドッグなら再起動時に、
「SoftDog: Initiating system reboot.」
のログが、kern.logに出力されるので、ログファイルを見れば確認可能、
という認識でよろしいでしょうか？
（当方まだ確認しておらず出力されるか否かの知りたく）
よろしくお願いします。
at_mizo
溝渕です。
ご説明いただきありがとうございます。
> 結論、ソフトウェアウォッチドッグなら再起動時に、
> 「SoftDog: Initiating system reboot.」
> のログが、kern.logに出力されるので、ログファイルを見れば確認可能、
> という認識でよろしいでしょうか？
> （当方まだ確認しておらず出力されるか否かの知りたく）
Linuxカーネルソースを確認してみましたが、critical levelの"SoftDog: Initiating system reboot."ログが出力されます。その後、すぐにresetされるので、loggerが拾う時間が無いように思います。
目的はアプリケーションの死活監視だと思いますので、アプリケーション内の起動と終了時にloggerにメッセージを投げると、判断できませんでしょうか?
例えば、このような判断はどうでしょうか?
Mar 24 13:50:55 [HOSTNAME] user-app[PID]: start Mar 24 13:51:14 [HOSTNAME] user-app[PID]: stop //正常終了したと判断できる Mar 24 13:51:42 [HOSTNAME] user-app[PID]: start Mar 24 13:53:05 [HOSTNAME] user-app[PID]: start //終了せずに再度開始しているので、直前に異常終了したと判断できる
eqc_1101
at_mizo
溝渕です。
> 対象ログが出力されるよう実装されているがloggerが拾えないと思う為、
> 実質kern.logには記録されない、ということで承知しました。
ちなみにですが、上記のような状況を救う為に、Kdumpという仕組みがあります。
https://armadillo.atmark-techno.com/forum/armadillo/13490
要件に合致するようでしたら利用してみてください。
eqc_1101
at_mizo
2023年3月23日 12時25分
溝渕です。
> 今検討しているのは、ユーザーアプリケーションでも別途リブートする処理を実装しているため、
> 再起動の要因を判別したく考えております。
>
> ①ユーザーアプリケーションによる再起動
> ②ハードウェアウォッチドッグタイマーによる再起動
>
> ①については、作成するユーザーアプリケーションにて判断できるため問題ないのですが、
> ②についてはどう判断すべきか分かりません。
前提として、i.MXの実装では再起動は全てハードウェアウォッチドッグタイマーによるリセットが入ります。その為、リセット後では再起動の要因を把握することはできません。
なので、アプリケーションでリセット前にログを残すする必要があります。
起動要因については、次のように確認できると思います。