manabu-yoshioka-arc
2024年7月5日 3時34分
お世話になっております。
Armadillo-IOT A6 を使用した機器の連続試験において、不定期にリブートがかかる状態が出ています。
頻度は 14日間の連続テストで15回、発生しない時は3日間連続で出ない時もありますが、発生する時は1日に3回発生している時もあります。
ちなみにリブートの確認は、ブート時に対向サーバにブートの報告を LTE 通信経由で上げているのでそのログでの確認です。
別途監視カメラで撮影も行っており、そちらでの検証はできるのですが、まだ解析はできていない状況です。
テストは2台で行っており、うち1台でリブートの問題が出ています。もう一台には出ていません。
現象から、LTE通信部分でのリブート、または電源電圧低下によるリブートではないかと考えています。
1. LTE通信でのリブートするかしないかの設定の確認箇所(connection-recover.conf など)を教えてください。確認します。
2. LTE通信でのリブートが発生した場合のアルマジロ内のログがあるはずであれば、その場所を教えてください。(現在 overlay 効かせてます)
3. 電源で夏低下でのリブートが発生した場合のアルマジロ内のログがあるはずであれば、その場所を教えてください。(現在 overlay 効かせてます)
その他、御社の知見で、こういう事例があったというものがあれば情報いただけると助かります。
よろしくお願いします。
コメント
manabu-yoshioka-arc
ご回答ありがとうございます。質問がわかりにくかったでしょうか。すみません。
電源のドロップと同様に、LTE 回路の設定や動作でリセットがかかっているのではと疑っております。のでそちらについてのみ、ご回答いただければと思います。
overlay を外せば、通信部分のログが残すような設計になっていないでしょうか。そうなっているならそのファイル位置を教えてください。
例えば PING が通らなくなったのでリブートに入る、と言うような自発的なリブートの証拠みたいなものが掴めないかと期待しています。
また、
> > 1. LTE通信でのリブートするかしないかの設定の確認箇所(connection-recover.conf など)を教えてください。確認します。
についても回答をお願いします。リブートの設定は false にしているつもりですが、間違いがないかどうか確認しておきたいのです。
設定ファイルの位置も、フルパスで明示をお願いします。
よろしくお願いします。
at_mizo
溝渕です。
こちらこそ意図を汲み取れておらず、すみませんでした。
> 電源のドロップと同様に、LTE 回路の設定や動作でリセットがかかっているのではと疑っております。のでそちらについてのみ、ご回答いただければと思います。
リブートするのは、「Armadillo-IOT A6」ではなく、「LTEモジュール」という認識で宜しいでしょうか?
私は、「Armadillo-IOT A6」がリブートするとの認識で回答しており、その場合はリセット要因が何であったとしてもログは残らない事が大半であると回答しました。
質問を質問で返して申し訳ございませんが、まずは問題となっている現象を把握したいので、上記回答をお願いいたします。
manabu-yoshioka-arc
回答ありがとうございます。
「Armadillo-IOT A6」がリブートしています。
正確には、crontab に @reboot で登録した シェルスクリプトが、弊社サーバに向かって、「私(リブートのシェルスクリプト)が走りました」と言いうメッセージを発しています。(「Armadillo-IOT A6」は外部の LED 表示装置の制御に利用しており、もともと連続稼働テスト中に表示が電源投入時の表示になるという報告を受けて追加したプログラムがこのシェルスクリプトです)
ご回答によると、PING をうってリブートすると言うのは、LTE 回路だけなのでしょうか。私はてっきり 「Armadillo-IOT A6」とは LTE 回路を含むシステムであり、通信部で異常が起こったら(PING をうってレスポンスがなかったら)「Armadillo-IOT A6」丸ごとリセットするプログラム(設定)があるのだとマニュアルを読み違えておりました。
ですので、その設定は False にしたはずだけども、この不具合の原因かもしれないので確認しておこう、間違った設定ファイルだと深みにはまって行くのでと思い、質問させていただいた次第です。
つまり、
通信部分で「Armadillo-IOT A6」自体を Reboot する回路もプログラムはない、
PING が通らなくなってリセットするプログラムが仮に走ったとしても、LTE 回路だけのリセットである、
私の述べた症状(crontab に設定した @reboot 部分が走っている)ことから、「Armadillo-IOT A6」のリブートが起こっていることは間違いない(ログは取れない)
と言うことでよろしいでしょうか。
ご確認お願いいたします。
at_mizo
溝渕です。
ご回答ありがとうございます。
> 「Armadillo-IOT A6」がリブートしています。
> 正確には、crontab に @reboot で登録した シェルスクリプトが、弊社サーバに向かって、「私(リブートのシェルスクリプト)が走りました」と言いうメッセージを発しています。
了解です。
> ご回答によると、PING をうってリブートすると言うのは、LTE 回路だけなのでしょうか。私はてっきり 「Armadillo-IOT A6」とは LTE 回路を含むシステムであり、通信部で異常が起こったら(PING をうってレスポンスがなかったら)「Armadillo-IOT A6」丸ごとリセットするプログラム(設定)があるのだとマニュアルを読み違えておりました。
Armadillo-IoT A6Eの場合は、上記ご認識で合っています。
今回ご利用されているArmadillo-IoT A6には上記機能は存在しません。
> 通信部分で「Armadillo-IOT A6」自体を Reboot する回路もプログラムはない、
> PING が通らなくなってリセットするプログラムが仮に走ったとしても、LTE 回路だけのリセットである、
> 私の述べた症状(crontab に設定した @reboot 部分が走っている)ことから、「Armadillo-IOT A6」のリブートが起こっていることは間違いない(ログは取れない)
> と言うことでよろしいでしょうか。
概ね合っています。
問題を解決していくには、リブートの要因を特定する必要があるかと思います。
コンソール(Debug UART)を接続しておくと、(ログファイルとして残せない)ログが再起動する際に出力される場合があります。コンソールを接続しておく事は可能ですか?
manabu-yoshioka-arc
at_mizo
manabu-yoshioka-arc
時間がかかってしまいましたが、リブートする問題について、その後の調査結果とターミナルログが取れましたので、相談を再開させてください。
問題整理のために症状を再掲しておきます。
- Armadillo-IOT-A6 を利用した IOT 機器を開発中です。
- 長期間のランニングテストを行なっていたところ、1-2週間に数回程度、リブートする症状が確認されている。不定期。1日に2回起こることもあるが、1週間に1度も起こらない時もある。
過去に質問と回答から行なって来たこと
- 電源ドロップなどの問題が発生していないか -> オシロにてトリガーをかけてみてはどうかとのアドバイスをいただきました。
- overlay を効かせたシステムなのでログが取れない -> ターミナルを接続し、その結果をロギングすれば良いのではとのアドバイスをいただきました。
結果
- オシロを繋いで症状を観察。問題発生時にトリガーはかからなかった。
また定電圧電源を繋ぎ、電圧と下げて動作するかどうかの確認も行った。3.5V まで低下させてもアルマジロとプログラムは正常に動作。3.4V まで下げると停止、もちろんそのままの電圧では再起動しない。電圧を上げるとリブートした。
- ターミナルを繋ぎターミナルのログを取得。
問題発生時に突然のリブートしか発生していないようにみえた。
自作したアプリ側のエラーが原因かもしれないとそこにもターミナルに記録を出すようにしたが出ていない。
overlay 使用時のメモリ不足を疑い、またoverlay を外せばシステムのどこかにログが残るかももしれないと期待し、overlay を外した。結果症状がやっと出て、ログが取れた。
その時のターミナルのログを添付します。
9月10日に2回も発生しました。お手数ですがログを見ていただき、何かアドバイスいただけると助かります。
ターミナルログを見る限り、通常のプロンプトが表示されてから、突然リブートしているように読めています。
-- reboot-20240910_1753-terminal.log -- 15行目でその前の定期的かつ計画通りの reboot が終了し、単なるプロンプトが表示。17行目が おおよそ17:53時点でそこからリブートしています。Reset cause: POR の文字が見えますが、電源に接続したオシロには何も反応なしです。
-- reboot-20240910_2120-terminal.log -- 上のログに示したリブートのあと、約4.5時間後に reboot した結果です。同じく 15行目に普通のプロンプトを表示した後、突然 17行目からリブートが始まっています。
追加で教えていただきたいこと
overlay を外してもトラブルが再現できていますので、/var 以下にログなどは残っていないでしょうか。あればファイルの場所をお教えください。
その他参考になればと思い追加の状況です。
- 同じ機器をもう一台作成し、テストをしています。トラブルの発生している機器には10分に1回、外部のセンサーをON/OFFするテスト回路を追加して動かしています。新たな機器にはその回路はつけていません。トラブルは外部のセンサーをON/OFFするテスト回路を追加した機器にだけ発生しています。ただし不定期です。よって私の作成したアプリケーションプログラムのどこかが関係しているのではないかと考え、エラーが出たらターミナルに文字表示をするように思いつく限りの場所に仕込んでいますが、ターミナルログにその記録はありません。エラーを発生させた場合にターミナルに文字が出ることは確認してあります。24時間機器の動画を撮影し、トラブルが発生したかどうかは動画ででも確認できるようにしてあります。
- 屋外に設置する機器であるため、毎時 0:30 分にリブートするようにしています。メモリリークなどのトラブルを避けたいためです。これは cron で設定しています。プログラムのユーザレベルで動かしており、全ては cron で行っています。
- WDT の機能は armadillo-IOT-A6 には入っていないと理解しており、その辺りの調査は行っていません。
よろしくお願いします。
ファイル | ファイルの説明 |
---|---|
reboot-20240910_1753-terminal.log | 9/10の17:53分にリブートした時のターミナルのログ |
reboot-20240910_2120-terminal.log | 9/10の21:20分にリブートした時のターミナルのログ |
at_mizo
溝渕です。
回答遅くなり申し訳ございません。また、ログのご提供ありがとうございます。
> 追加で教えていただきたいこと
> overlay を外してもトラブルが再現できていますので、/var 以下にログなどは残っていないでしょうか。あればファイルの場所をお教えください。
ログは/var/log/以下に記録されます。ただ、コンソールに何も表示されずにリセットしている事から、有益なログが保存できている可能性は低いかなと思います。
> - 同じ機器をもう一台作成し、テストをしています。トラブルの発生している機器には10分に1回、外部のセンサーをON/OFFするテスト回路を追加して動かしています。新たな機器にはその回路はつけていません。トラブルは外部のセンサーをON/OFFするテスト回路を追加した機器にだけ発生しています。
問題が再現できる最小限のプログラムを提供いただく事は可能ですか? ご提供いただけますと、こちらで再現確認および修正ができる可能性があります。
> - WDT の機能は armadillo-IOT-A6 には入っていないと理解しており、その辺りの調査は行っていません。
armadillo-IOT-A6ではデフォルトソフトウェアでWDTが有効になっています。その為、Linuxカーネルが一定期間WDTをkickできない状況に陥るとresetします。
manabu-yoshioka-arc
色々情報ありがとうございます。
その後の調査・実験で、かなり高い確率でリブートの事象を発生させることができるようになってきました。
WDT によるリブートの可能性がかなり高く、私が作成したアプリ側の、特に ppp0 利用の通信プログラムのエラー処理に問題がありそうです。
追加で2つお教えください。
1) WDT のタイムアウトは120秒とお聞きしていたのですが、症状を観察していたところ、60秒ではないでしょうか。WDT のトリガがかかる秒数をお教えください。
2) アプリ側のログを記録する際に armadillo でお勧めの方法があればお教えください。syslog を当初使おうと思ったのですがそのコードを入れた途端エラーなのかリブートが常時かかってしまったようで、現在は自作の fopen , fwrite で凌いでいます。色々追い込みたい部分がございますので、OS でサポートされているログの仕組みが使えるなら、使って時間短縮を図りたいと考えています。syslog 使えるはずです、という回答でも結構です。またディレクトリの権限などで注意がございましたら、お教えいただけると助かります。
at_shinya.koga
アットマークテクノの古賀です。
manabu-yoshioka-arcさん:
>色々情報ありがとうございます。
>その後の調査・実験で、かなり高い確率でリブートの事象を発生させることができるようになってきました。
>WDT によるリブートの可能性がかなり高く、私が作成したアプリ側の、特に ppp0 利用の通信プログラムのエラー処理に問題がありそうです。
>追加で2つお教えください。
>1) WDT のタイムアウトは120秒とお聞きしていたのですが、症状を観察していたところ、60秒ではないでしょうか。WDT のトリガがかかる秒数をお教えください。
Linux カーネルが使う WDT ドライバは、デフォルトで60秒に設定していますので、60秒で正しいと思います:
https://github.com/atmark-techno/linux-4.14-at/blob/master/drivers/watc…
https://github.com/atmark-techno/linux-4.14-at/blob/master/drivers/watc…
>2) アプリ側のログを記録する際に armadillo でお勧めの方法があればお教えください。syslog を当初使おうと思ったのですがそのコードを入れた途端エラーなのかリブートが常時かかってしまったようで、現在は自作の fopen , fwrite で凌いでいます。色々追い込みたい部分がございますので、OS でサポートされているログの仕組みが使えるなら、使って時間短縮を図りたいと考えています。syslog 使えるはずです、という回答でも結構です。またディレクトリの権限などで注意がございましたら、お教えいただけると助かります。
「かなり高い確率でリブートの事象を発生させることができるようになってきました」とのことですので、もしアプリケーションをシェルから起動して動作させられるのであれば、printf() で標準出力にログを出し、それを 、接続した PC のシリアルコンソールで観測する、というのは、いかがでしょうか?
ところで、syslog によるログ出力を行なおうとした途端にリブートが常時かかるようになった、ということですが、syslog によるログ出力だけを行う小さいアプリケーションを作って動かした場合にも、同じ症状が起きるでしょうか。もし起きる場合は、syslog 出力するコードを頂ければと思います。
manabu-yoshioka-arc
manabu-yoshioka-arc
本件ですが、リブートの原因は WDT によるリブートで間違いないようです。長らくお付き合いありがとうございました。
待ち発生プロセスに timout コマンドをかける処理で対処し、ランニングテストで不定期なリブートは発生しなくなりました。
詳細
私の方で作成し、起動しているプロセス2つ、両方とも LTE 回線経由のサーバとの通信プロセスなのですが、うち一つで長い待ちになる場合があることがわかり、もう一つのプロセス= HTTPS で自前サーバーとの通信でエラーログを responce で返すようにしかつエラーが発生した場合に、WDT によるリブートを発生させることができました。確実な証拠ログを得られたわけではないのですが、最初のプロセスに timeout コマンドでの強制リスタートをかけ、もう一つのプロセスに関係するサーバの設定で、エラーログを responce に含めないようにした結果、2週間*4台のランニングテストで、不定期なリブート症状は一度も確認できませんでした。
以上、ありがとうございました。
at_mizo
2024年7月5日 9時41分
溝渕です。
> 1. LTE通信でのリブートするかしないかの設定の確認箇所(connection-recover.conf など)を教えてください。確認します。
> 2. LTE通信でのリブートが発生した場合のアルマジロ内のログがあるはずであれば、その場所を教えてください。(現在 overlay 効かせてます)
> 3. 電源で夏低下でのリブートが発生した場合のアルマジロ内のログがあるはずであれば、その場所を教えてください。(現在 overlay 効かせてます)
上記、いずれも確認不可能と思います。
リブートが発生 == Linuxカーネルが動作できない状況
とみるのが妥当と思います。Linuxカーネルが動作できない状態で、ログ出力(ファイルシステムへの書き出し)はできない事が大半です。
> その他、御社の知見で、こういう事例があったというものがあれば情報いただけると助かります。
リブート発生時、コンソール(Debug UART)にエラー内容が表示される場合があります。また、電圧ドロップを疑っているのであれば、オシロスコープで電源電圧をトリガをかけて監視しておくと良いと思います。