uen2825
2023年11月22日 21時32分
いつもお世話になっております。
LTE接続でコンテナ起動した場合、通常は問題なく接続できます。
コンテナ終了時に電源を落とす設定にすると、自動起動するプログラムに行く前に落ちてしまいます。
/etc/containers/aiot_gw_container_hooks.d/hook.shに/sbin/poweroffを追加
LAN接続の場合どちらも正常に動作します。
どこかでLTE接続までのタイムアウトを設定できるところは無いでしょうか？
コメント
uen2825
古賀様
いつもありがとうございます。
説明不足申し訳ございません。
> 1.) 「コンテナ終了時に電源を落とす設定にすると、自動起動するプログラムに行く前に落ちてしまいます。」とおっしゃっている、「自動起動するプログラムに行く前に」というのは、次のどの状況でしょうか？
>
> 1-a.) コンテナ終了をトリガーとして poweroff した後、AC アダプタを抜き差しするなどして Armadillo に電源を投入し直し、起動した際の、自動起動する設定のコンテナが起動する際の挙動（コンテナが実行するプログラムの初期化処理でエラーする）。
こちらになります。
> 2.) 「LTE接続でコンテナ起動した場合、通常は問題なく接続できます。」とおっしゃっている「通常は」というのは、(1) で「落ちてしまう」場合と、どのようにプログラム起動順序が違うのでしょうか？手順の違いを教えてください。
「通常は」意味不明でした申し訳ございません。。
ここで書いた「通常は」は、コンテナ終了をトリガーとして poweroff しない事を書きました。
プログラム起動順序は同じです。
A6EのLANが差さっているとうまくいきます。
・コンテナ終了をトリガーとして poweroff した時 >> 成功
・コンテナ終了をトリガーとして poweroff しない時 >> 成功
LANを抜いた時
・コンテナ終了をトリガーとして poweroff した時 >> コンテナ内の処理をしないで抜けてしまいます
・コンテナ終了をトリガーとして poweroff しない時 >> 成功
不明な点ございましたらお聞きください。
宜しくお願い申し上げます。
koga
アットマークテクノの古賀です。
uen2825さん：
>いつもありがとうございます。
>説明不足申し訳ございません。
あ、いえいえ。お返事有難うございます。
>>1.) 「コンテナ終了時に電源を落とす設定にすると、自動起動するプログラムに行く前に落ちてしまいます。」とおっしゃっている、「自動起動するプログラムに行く前に」というのは、次のどの状況でしょうか？
>>
>> 1-a.) コンテナ終了をトリガーとして poweroff した後、AC アダプタを抜き差しするなどして Armadillo に電源を投入し直し、起動した際の、自動起動する設定のコンテナが起動する際の挙動（コンテナが実行するプログラムの初期化処理でエラーする）。
>
>こちらになります。
了解しました。
>>2.) 「LTE接続でコンテナ起動した場合、通常は問題なく接続できます。」とおっしゃっている「通常は」というのは、(1) で「落ちてしまう」場合と、どのようにプログラム起動順序が違うのでしょうか？手順の違いを教えてください。
>
>「通常は」意味不明でした申し訳ございません。。
>ここで書いた「通常は」は、コンテナ終了をトリガーとして poweroff しない事を書きました。
>プログラム起動順序は同じです。
これについても、了解しました。
>A6EのLANが差さっているとうまくいきます。
LAN ケーブルを差している時はエラーしないというのは、LAN 経由でインターネット接続できるからなのでしょうね。
>LANを抜いた時
>・コンテナ終了をトリガーとして poweroff した時 >>コンテナ内の処理をしないで抜けてしまいます
>・コンテナ終了をトリガーとして poweroff しない時 >> 成功
>
>不明な点ございましたらお聞きください。
「コンテナ終了をトリガーとして poweroff しない時」についてですが、この設定にした状態で、Base OS のシェルで poweroff コマンドを実行し、AC アダプタを抜いた後、電源を投入して最初に起動した場合もエラーしないということでしょうか？
つまり、コンテナ終了をトリガーとして自動 poweroff した後、電源を再投入して起動した場合にエラーするのと同様に、コンテナ終了をトリガーとせずに poweroff した後の起動でもエラーするのか、あるいは、自動 poweroff した時にだけエラーするのか、ということです。
AC アダプタを抜いて Armadillo に給電オフした後、電源投入して起動する時の状態は、コンテナ終了をトリガーとして自動 poweroff していたのかどうかに関係ないはずですので、同様にエラーするのではないかと思います。が、お手元の環境で、そうなのかどうかを念のため確認する次第です。
LAN ケーブルを接続しないで LTE でのみインターネット接続する場合は、コンテナ終了をトリガーとして自動 poweroff するかどうかに関わらず、電源投入した直後のコンテナ起動にエラーするのであれば、LTE モジュールが動作開始するまでに要する時間と、コンテナが起動するタイミングとの関係が要因だと思います。その場合は、コンテナで実行するプログラムの初期化処理の手順で調整するのが簡単かも知れません。
以上、ひとまずのコメントです。
uen2825
古賀様
ありがとうございます。
> 「コンテナ終了をトリガーとして poweroff しない時」についてですが、この設定にした状態で、Base OS のシェルで poweroff コマンドを実行し、AC アダプタを抜いた後、電源を投入して最初に起動した場合もエラーしないということでしょうか？
はいそうです。
> つまり、コンテナ終了をトリガーとして自動 poweroff した後、電源を再投入して起動した場合にエラーするのと同様に、コンテナ終了をトリガーとせずに poweroff した後の起動でもエラーするのか、あるいは、自動 poweroff した時にだけエラーするのか、ということです。
>
> AC アダプタを抜いて Armadillo に給電オフした後、電源投入して起動する時の状態は、コンテナ終了をトリガーとして自動 poweroff していたのかどうかに関係ないはずですので、同様にエラーするのではないかと思います。が、お手元の環境で、そうなのかどうかを念のため確認する次第です。
どちらのoffでも同じ動作です。
> LAN ケーブルを接続しないで LTE でのみインターネット接続する場合は、コンテナ終了をトリガーとして自動 poweroff するかどうかに関わらず、電源投入した直後のコンテナ起動にエラーするのであれば、LTE モジュールが動作開始するまでに要する時間と、コンテナが起動するタイミングとの関係が要因だと思います。その場合は、コンテナで実行するプログラムの初期化処理の手順で調整するのが簡単かも知れません。
プログラムの初期化処理とはどのような事でしょうか
以下のようにするとip timeout:20とありますが、こちらを変更して試すことは出来ないでしょうか
armadillo:~# mmcli -b 0
Status | connected: yes
| suspended: no
| multiplexed: no
| interface: ttyMux1
| ip timeout: 20
| profile id: 1
koga
アットマークテクノの古賀です。
uen2825さん：
>>「コンテナ終了をトリガーとして poweroff しない時」についてですが、この設定にした状態で、Base OS のシェルで poweroff コマンドを実行し、AC アダプタを抜いた後、電源を投入して最初に起動した場合もエラーしないということでしょうか？
>
>はいそうです。
というお返事の内容（コンテナ終了をトリガーとして poweroff しない設定で、電源オフしてから電源を投入し直して最初に起動した場合はエラー *しない*）と、以下は矛盾していますが、どちらが正しいでしょうか？
>>つまり、コンテナ終了をトリガーとして自動 poweroff した後、電源を再投入して起動した場合にエラーするのと同様に、コンテナ終了をトリガーとせずに poweroff した後の起動でもエラーするのか、あるいは、自動 poweroff した時にだけエラーするのか、ということです。
>>
>>AC アダプタを抜いて Armadillo に給電オフした後、電源投入して起動する時の状態は、コンテナ終了をトリガーとして自動 poweroff していたのかどうかに関係ないはずですので、同様にエラーするのではないかと思います。が、お手元の環境で、そうなのかどうかを念のため確認する次第です。
>
>どちらのoffでも同じ動作です。
後者（どちらの設定の場合も、電源オフしてから電源を投入し直して最初に起動した場合はエラーする）が正しいでしょうか？
以下、後者が正しいと推測して進めます。前者が正しいのであれば、ごめんなさい。
>>LAN ケーブルを接続しないで LTE でのみインターネット接続する場合は、コンテナ終了をトリガーとして自動 poweroff するかどうかに関わらず、電源投入した直後のコンテナ起動にエラーするのであれば、LTE モジュールが動作開始するまでに要する時間と、コンテナが起動するタイミングとの関係が要因だと思います。その場合は、コンテナで実行するプログラムの初期化処理の手順で調整するのが簡単かも知れません。
>
>プログラムの初期化処理とはどのような事でしょうか
動かしていらっしゃるプログラム次第です。動かしていらっしゃるプログラムは、次のどれでしょうか？
a.) ゲートウェイコンテナに収録されている、当社からリリースしたゲートウェイコンテナアプリケーション
b.) 当社からリリースしたゲートウェイコンテナアプリケーションをカスタマイズしたアプリケーション
c.) ご自分で作成されたアプリケーション
もし (c) であれば、ご自分で作成されたアプリケーションが、起動途中でエラーしている箇所より前に行っているのが初期化処理です。
(a) の場合には、当社からリリースしているゲートウェイコンテナアプリケーションの不具合かも知れませんので、その場合は調査します。
ちなみに、11/20 に以下の投稿でおっしゃっていた問題は、現在お困りになっている症状と同様、LTE 接続のみで起動しようとした場合に起きていたのではないかと思いますが、いかがでしょうか？
コンテナを停止させる方法
https://armadillo.atmark-techno.com/forum/armadillo/17795
>以下のようにするとip timeout:20とありますが、こちらを変更して試すことは出来ないでしょうか
>armadillo:~# mmcli -b 0
> Status | connected: yes
> | suspended: no
> | multiplexed: no
> | interface: ttyMux1
> | ip timeout: 20
> | profile id: 1
こちらの設定でタイムアウト時間を延ばせるとしても、それでは改善しないような気がします。
ひとまず、上記の質問（動かしていらっしゃるプログラムが、どのようなものか）について、教えてくださいませ。
uen2825
古賀様
ありがとうございます。
> >>「コンテナ終了をトリガーとして poweroff しない時」についてですが、この設定にした状態で、Base OS のシェルで poweroff コマンドを実行し、AC アダプタを抜いた後、電源を投入して最初に起動した場合もエラーしないということでしょうか？
> >
> >はいそうです。
>
> というお返事の内容（コンテナ終了をトリガーとして poweroff しない設定で、電源オフしてから電源を投入し直して最初に起動した場合はエラー *しない*）と、以下は矛盾していますが、どちらが正しいでしょうか？
>
> >>つまり、コンテナ終了をトリガーとして自動 poweroff した後、電源を再投入して起動した場合にエラーするのと同様に、コンテナ終了をトリガーとせずに poweroff した後の起動でもエラーするのか、あるいは、自動 poweroff した時にだけエラーするのか、ということです。
> >>
> >>AC アダプタを抜いて Armadillo に給電オフした後、電源投入して起動する時の状態は、コンテナ終了をトリガーとして自動 poweroff していたのかどうかに関係ないはずですので、同様にエラーするのではないかと思います。が、お手元の環境で、そうなのかどうかを念のため確認する次第です。
> >
> >どちらのoffでも同じ動作です。
「コンテナ終了をトリガーとして poweroff する時」と「LTEのみ接続」の場合のみ、コンテナ内のプログラムを実行しません。
> 後者（どちらの設定の場合も、電源オフしてから電源を投入し直して最初に起動した場合はエラーする）が正しいでしょうか？
> 以下、後者が正しいと推測して進めます。前者が正しいのであれば、ごめんなさい。
>
> >>LAN ケーブルを接続しないで LTE でのみインターネット接続する場合は、コンテナ終了をトリガーとして自動 poweroff するかどうかに関わらず、電源投入した直後のコンテナ起動にエラーするのであれば、LTE モジュールが動作開始するまでに要する時間と、コンテナが起動するタイミングとの関係が要因だと思います。その場合は、コンテナで実行するプログラムの初期化処理の手順で調整するのが簡単かも知れません。
> >
> >プログラムの初期化処理とはどのような事でしょうか
>
> 動かしていらっしゃるプログラム次第です。動かしていらっしゃるプログラムは、次のどれでしょうか？
>
> a.) ゲートウェイコンテナに収録されている、当社からリリースしたゲートウェイコンテナアプリケーション
>
> b.) 当社からリリースしたゲートウェイコンテナアプリケーションをカスタマイズしたアプリケーション
>
> c.) ご自分で作成されたアプリケーション
c.) ご自分で作成されたアプリケーションです。
> ちなみに、11/20 に以下の投稿でおっしゃっていた問題は、現在お困りになっている症状と同様、LTE 接続のみで起動しようとした場合に起きていたのではないかと思いますが、いかがでしょうか？
>
> コンテナを停止させる方法
> https://armadillo.atmark-techno.com/forum/armadillo/17795
この時はプログラムにバグがあり、その影響かと思います。
>
> >以下のようにするとip timeout:20とありますが、こちらを変更して試すことは出来ないでしょうか
> >armadillo:~# mmcli -b 0
> > Status | connected: yes
> > | suspended: no
>
> こちらの設定でタイムアウト時間を延ばせるとしても、それでは改善しないような気がします。
> ひとまず、上記の質問（動かしていらっしゃるプログラムが、どのようなものか）について、教えてくださいませ。
こちらの件、承知しました。
コンテナの中にプログラム起動行が入っています。
プログラム行前の個所が初期化処理になるのでしょうか。
コンテナを添付いたしますのでご指導いただけないでしょうか
| ファイル | ファイルの説明 |
|---|---|
| a6e-gw-container.conf |
uen2825
at_shinya.koga
アットマークテクノの古賀です。
uen2825さん（2023年11月24日 15時23分）：
>>というお返事の内容（コンテナ終了をトリガーとして poweroff しない設定で、電源オフしてから電源を投入し直して最初に起動した場合はエラー *しない*）と、以下は矛盾していますが、どちらが正しいでしょうか？
>>
>>>>つまり、コンテナ終了をトリガーとして自動 poweroff した後、電源を再投入して起動した場合にエラーするのと同様に、コンテナ終了をトリガーとせずに poweroff した後の起動でもエラーするのか、あるいは、自動 poweroff した時にだけエラーするのか、ということです。
>>>>
>>>>AC アダプタを抜いて Armadillo に給電オフした後、電源投入して起動する時の状態は、コンテナ終了をトリガーとして自動 poweroff していたのかどうかに関係ないはずですので、同様にエラーするのではないかと思います。が、お手元の環境で、そうなのかどうかを念のため確認する次第です。
>>>
>>>どちらのoffでも同じ動作です。
>
>「コンテナ終了をトリガーとして poweroff する時」と「LTEのみ接続」の場合のみ、コンテナ内のプログラムを実行しません。
ごめんなさい。この回答ですと、分からないです。
「コンテナ終了をトリガーとして poweroff する時」と「LTEのみ接続」は、OR 結合（どちらか一方が成立するか、または両方が成立した場合に、コンテナ内のプログラムが終了してしまう）のでしょうか？あるいは、AND 結合なのでしょうか？
>>後者（どちらの設定の場合も、電源オフしてから電源を投入し直して最初に起動した場合はエラーする）が正しいでしょうか？
>>以下、後者が正しいと推測して進めます。前者が正しいのであれば、ごめんなさい。
もし、上記が OR 結合であり、LAN 接続していても、「コンテナ終了をトリガーとして poweroff する時」はコンテナ内のプログラムが終了し、「コンテナ終了をトリガーとして poweroff しない時」はプログラムが終了しないのであれば、僕の推測が違っています。その場合は、調査の切り口を変えないといけません。
ということで、再度回答をお願いします。
>>動かしていらっしゃるプログラム次第です。動かしていらっしゃるプログラムは、次のどれでしょうか？
>>
>>a.) ゲートウェイコンテナに収録されている、当社からリリースしたゲートウェイコンテナアプリケーション
>>
>>b.) 当社からリリースしたゲートウェイコンテナアプリケーションをカスタマイズしたアプリケーション
>>
>>c.) ご自分で作成されたアプリケーション
>
>c.) ご自分で作成されたアプリケーションです。
(c) ですね。了解しました。ちなみに、(a) の場合は、コンテナ内のプログラムが自動終了してしまう症状が起きないでしょうか？
>>ちなみに、11/20 に以下の投稿でおっしゃっていた問題は、現在お困りになっている症状と同様、LTE 接続のみで起動しようとした場合に起きていたのではないかと思いますが、いかがでしょうか？
>>
>> コンテナを停止させる方法
>> https://armadillo.atmark-techno.com/forum/armadillo/17795
>この時はプログラムにバグがあり、その影響かと思います。
その後、プログラムを修正されたということですね？
>>>プログラムの初期化処理とはどのような事でしょうか
…
>コンテナの中にプログラム起動行が入っています。
>プログラム行前の個所が初期化処理になるのでしょうか。
>コンテナを添付いたしますのでご指導いただけないでしょうか
添付して頂いた a6e-gw-container.conf を拝見したところ、コンテナに実行させるプログラムを指定する set_command 行は、次の内容ですね：
set_command python3 /root/gw_container/customize/main.py
僕が行っていた「初期化処理」は、main.py の中の、プログラムが最初に実行する処理のことです。
uen2825さん（2023年11月25日 15時28分）：
>一緒にログも付けさせてください。
このログには、コンテナ内で起動したプログラムのログが出ていませんので、状況が分かりません。
もし、「コンテナ終了をトリガーとして poweroff しない時」も、コンテナ内のプログラムが終了する症状が起きるのであれば、Base OS にログインした後、次のコマンドを実行すれば、main.py から出力したログを見ることができます。何かログが出ていないか、見てみてくださいませ：
podman logs a6e-gw-container
uen2825
> アットマークテクノの古賀です。
>
> uen2825さん（2023年11月24日 15時23分）：
> >>というお返事の内容（コンテナ終了をトリガーとして poweroff しない設定で、電源オフしてから電源を投入し直して最初に起動した場合はエラー *しない*）と、以下は矛盾していますが、どちらが正しいでしょうか？
> >>
> >>>>つまり、コンテナ終了をトリガーとして自動 poweroff した後、電源を再投入して起動した場合にエラーするのと同様に、コンテナ終了をトリガーとせずに poweroff した後の起動でもエラーするのか、あるいは、自動 poweroff した時にだけエラーするのか、ということです。
> >>>>
> >>>>AC アダプタを抜いて Armadillo に給電オフした後、電源投入して起動する時の状態は、コンテナ終了をトリガーとして自動 poweroff していたのかどうかに関係ないはずですので、同様にエラーするのではないかと思います。が、お手元の環境で、そうなのかどうかを念のため確認する次第です。
> >>>
> >>>どちらのoffでも同じ動作です。
> >
> >「コンテナ終了をトリガーとして poweroff する時」と「LTEのみ接続」の場合のみ、コンテナ内のプログラムを実行しません。
>
> ごめんなさい。この回答ですと、分からないです。
>
> 「コンテナ終了をトリガーとして poweroff する時」と「LTEのみ接続」は、OR 結合（どちらか一方が成立するか、または両方が成立した場合に、コンテナ内のプログラムが終了してしまう）のでしょうか？あるいは、AND 結合なのでしょうか？
AND結合です
> >>後者（どちらの設定の場合も、電源オフしてから電源を投入し直して最初に起動した場合はエラーする）が正しいでしょうか？
> >>以下、後者が正しいと推測して進めます。前者が正しいのであれば、ごめんなさい。
最初に起動した場合はエラーではなく、ずっとエラーです
エラーという表現が正しくありませんでした。コンテナに入り、すぐに抜けてしまう感じです。
> もし、上記が OR 結合であり、LAN 接続していても、「コンテナ終了をトリガーとして poweroff する時」はコンテナ内のプログラムが終了し、「コンテナ終了をトリガーとして poweroff しない時」はプログラムが終了しないのであれば、僕の推測が違っています。その場合は、調査の切り口を変えないといけません。
> ということで、再度回答をお願いします。
>
>
> >>動かしていらっしゃるプログラム次第です。動かしていらっしゃるプログラムは、次のどれでしょうか？
> >>
> >>a.) ゲートウェイコンテナに収録されている、当社からリリースしたゲートウェイコンテナアプリケーション
> >>
> >>b.) 当社からリリースしたゲートウェイコンテナアプリケーションをカスタマイズしたアプリケーション
> >>
> >>c.) ご自分で作成されたアプリケーション
> >
> >c.) ご自分で作成されたアプリケーションです。
>
> (c) ですね。了解しました。ちなみに、(a) の場合は、コンテナ内のプログラムが自動終了してしまう症状が起きないでしょうか？
元のa6e-gw-containerでしょうか？
> >>ちなみに、11/20 に以下の投稿でおっしゃっていた問題は、現在お困りになっている症状と同様、LTE 接続のみで起動しようとした場合に起きていたのではないかと思いますが、いかがでしょうか？
> >>
> >> コンテナを停止させる方法
> >> https://armadillo.atmark-techno.com/forum/armadillo/17795
> >この時はプログラムにバグがあり、その影響かと思います。
>
> その後、プログラムを修正されたということですね？
別のA6Eを使用しています。
> このログには、コンテナ内で起動したプログラムのログが出ていませんので、状況が分かりません。
> もし、「コンテナ終了をトリガーとして poweroff しない時」も、コンテナ内のプログラムが終了する症状が起きるのであれば、Base OS にログインした後、次のコマンドを実行すれば、main.py から出力したログを見ることができます。何かログが出ていないか、見てみてくださいませ：
>
> podman logs a6e-gw-container >
以下のコメントが表示されてしまいます。
armadillo:~# podman logs a6e-gw-container
ssse-flw: EmbSe_Init(): Entry
根本的に、LTEの設定がうまくいっていないのかも。と思い始めています。
at_shinya.koga
アットマークテクノの古賀です。
取り急ぎ一点、確認とお願いです。
uen2825さん：
>>ごめんなさい。この回答ですと、分からないです。
>>
>>「コンテナ終了をトリガーとして poweroff する時」と「LTEのみ接続」は、OR 結合（どちらか一方が成立するか、または両方が成立した場合に、コンテナ内のプログラムが終了してしまう）のでしょうか？あるいは、AND 結合なのでしょうか？
>
>AND結合です
となると、不思議ですね。それでは、「コンテナ終了をトリガーとして poweroff *しない*」設定にした時の、最初の起動時の状態を見てみたいので、以下の確認をお願いできますか：
1.) atmark-power-utils サービスの設定ファイル（/etc/atmark/power-utils.conf）で MODE の値を 'NONE' にしてから、このファイルを persist_file コマンドで永続化する：
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
2.) poweoff コマンドでシャットダウンした後、AC アダプタを抜き、差し直してから起動する。
3.) Base OS にログインして、次のコマンドを実行する：
# podman ps -a
なお、「コンテナ終了をトリガーとして poweroff する時」の動作では、power-utils.conf で MODE の値を 'SHUTDOWN' にしていらっしゃるという認識ですが、もし違いましたら、教えてください。
ところで、
>>>>後者（どちらの設定の場合も、電源オフしてから電源を投入し直して最初に起動した場合はエラーする）が正しいでしょうか？
>>>>以下、後者が正しいと推測して進めます。前者が正しいのであれば、ごめんなさい。
>
>最初に起動した場合はエラーではなく、ずっとエラーです
>エラーという表現が正しくありませんでした。コンテナに入り、すぐに抜けてしまう感じです。
コンテナが実行するプログラムが、エラーなどで終了すると、コンテナも終了します。そのため、「コンテナに入り、すぐに抜けてしまう感じ」の動作になります。そこは、僕がこれまでコメントしてきた想定通りです。
以上、取り急ぎ一点確認のお願いです。
この確認は、「LTEのみ接続」で、「コンテナ終了をトリガーとして poweroff しない時」（つまり、おっしゃっている AND 結合条件が成立しない時）にも、実はコンテナで実行するプログラムが終了しているのではないかを調べるためです。
uen2825
古賀様
お世話になります。
少し前のコメントで
下記ログを取るようにとの事でエラー発生時のログを取りました。
> podman logs a6e-gw-container
LANを抜いた時の状態です。LANケーブルを使ったネットワークから接続を繰り返し、LTEが確立した時に動作している感じがします。
古賀様の想定と一緒でした。
プログラムに30秒のウェイトを置くと思った通りの動作になりました。
ただ30秒のウェイトをおくよりも、LTEが確立して実行させたいと思っております。
LANケーブルを抜いてnmcliでネットワークデバイスを確認すると
LTEがeth0になる感じですが、あっていますでしょうか。
uen2825
at_shinya.koga
アットマークテクノの古賀です。
uen2825さん：
>別件で申し訳ございません。
こちらを先に回答しますね。
>マニュアルを見ているのですが、工場出荷状態に戻す方法が無いように思います。
>どこかに方法が載っていたら教えていただけないでしょうか。
A6E のマニュアルでは、「工場出荷状態」という文言ではなく「初期化」という文言で説明しています：
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
上の、「初期化インストールディスクの作成」で説明しているように、インストールディスクイメージをダウンロードして microSD カードに書込むと、その microSD カードが初期化インストールディスクになります。初期化インストールディスクで起動する（SD ブートする）ことにより、A6E のストレージ（eMMC）の内容が、工場出荷状態に初期化されます。
ご不明な点などありましたら、お知らせください。
at_shinya.koga
アットマークテクノの古賀です。
uen2825さん（2023年11月27日 19時48分）：
>少し前のコメントで
>下記ログを取るようにとの事でエラー発生時のログを取りました。
>>podman logs a6e-gw-container
>LANを抜いた時の状態です。LANケーブルを使ったネットワークから接続を繰り返し、LTEが確立した時に動作している感じがします。
>古賀様の想定と一緒でした。
了解しました。確認有り難うございます。
>プログラムに30秒のウェイトを置くと思った通りの動作になりました。
これについても、了解しました。
>ただ30秒のウェイトをおくよりも、LTEが確立して実行させたいと思っております。
そうですね。確実・堅牢なのは、プログラムが、次の挙動を行うことだと思います：
* 接続先サービスへの疎通を行った後に接続を試みるか、または、接続できないときはリトライ動作する。
* 通信中に接続が切れた時は、再接続動作を行う。
ちなみに、ゲートウェイコンテナのアプリケーションでは、このような動作を実装しています。
ゲートウェイコンテナのイメージにソースが入っていますが、
/usr/lib/python3.11/site-packages/atgateway/app/gw_app.py
にメインループの実装があり、上のような動作になっています。具体的には、mainloop() 関数から呼びだす GwApp.ready() が CloudAgent クラスのインスタンスの connect() を呼び出し、connect() が接続できずに False を返すと、再接続動作を行う GwApp.reconnect() を実行するタスク（async task）を生成します。
GwApp.reconnect() は、適当な間隔で（いまの実装では10秒）スリープしながら、接続先サービスとの接続が切れていれば接続を試行するリトライ動作を実行します。これにより、通信中に接続が切れた時の再接続動作も実現しているのです。
作成していらっしゃるプログラムを設計・実装するうえで、もし参考になりましたら幸いです。
>LANケーブルを抜いてnmcliでネットワークデバイスを確認すると
>LTEがeth0になる感じですが、あっていますでしょうか。
コンテナ内からホスト OS のネットワークインタフェースの状態をチェックするよりも、コンテナ内のアプリケーションが接続したいサービスとの疎通確認を行なう方が、コンテナに与える権限を少なくできるという点で良いのではないかと思います。
いかがでしょうか？
uen2825
at_shinya.koga
アットマークテクノの古賀です。
uen2825さん：
>mainloopを使用したサンプルはどこかにないでしょうか
>aw_app.pyのmainloopの引数が何を指しているのか難しく、難儀しております。
以下の Howto を、まだご覧になっていなければ、ご覧になってみてください：
Armadillo-IoT A6E のゲートウェイコンテナをカスタマイズする（センサ追加編）
https://armadillo.atmark-techno.com/node/13708
いかがでしょうか？
Howto の内容だけでは分からないところもあるかと思いますので、その場合は、遠慮なくご質問くださいませ。
uen2825
古賀様
お世話になっております。
mainloopを理解できなかったため、下記を参考に対応しました。
https://armadillo.atmark-techno.com/blog/11167/17337
電波状況を見て接続の確認をすることとしました。
別件の初期ディスクの件も無事にうまくいきました。
いろいろありがとうございました。
uen2825
申し訳ございません。
出来たと思っていたのですが、sleepを使用して試したところ
RS485で遷移しており、1度目はOKなのですが、2度目にNGとなってしまいます。
下記を参考に電波状況を確認しています。
> https://armadillo.atmark-techno.com/blog/11167/17337
> 電波状況を見て接続の確認をすることとしました。
mm_modem = MMModem()
m = mm_modem.signal_quality()
1度目は50前後の数値が出ており
2度目は動かないためログを確認しました。以下の内容です。
set_command sleep infinityだけのコンテナ内に入って実行した場合は、何回やってもエラーが出ません。
何かヒントでも教えて頂けますでしょうか
------------------------------
armadillo:~# podman logs a6e-gw-container
ssse-flw: EmbSe_Init(): Entry
App :INFO :Using PortName='/dev/i2c-1:0x48' (ENV: EX_SSS_BOOT_SSS_PORT=/dev/i2c-1:0x48)
sss :INFO :atr (Len=35)
00 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 08
01 00 00 00 00 64 00 00 0A 4A 43 4F 50 34 20 41
54 50 4F
sss :WARN :Communication channel is Plain.
sss :WARN :!!!Not recommended for production use.!!!
ssse-flw: Version: 1.0.5
ssse-flw: EmbSe_Init(): Exit
ssse-flw: Control Command EMBSE_LOG_LEVEL; requested log level = 4
Traceback (most recent call last):
File "/root/gw_container/customize/main.py", line 88, in
client.connect(hostname=host, username=host_username, password=host_password, timeout=10, look_for_keys=False)
File "/usr/lib/python3.11/site-packages/paramiko/client.py", line 365, in connect
sock.connect(addr)
OSError: [Errno 101] Network unreachable
at_shinya.koga
アットマークテクノの古賀です。
uen2825さん（2023年12月28日 23時28分）：
>申し訳ございません。
>出来たと思っていたのですが、sleepを使用して試したところ
>RS485で遷移しており、1度目はOKなのですが、2度目にNGとなってしまいます。
>下記を参考に電波状況を確認しています。
>>https://armadillo.atmark-techno.com/blog/11167/17337
>>電波状況を見て接続の確認をすることとしました。
> mm_modem = MMModem()
> m = mm_modem.signal_quality()
>1度目は50前後の数値が出ており
>2度目は動かないためログを確認しました。以下の内容です。
>set_command sleep infinityだけのコンテナ内に入って実行した場合は、何回やってもエラーが出ません。
>何かヒントでも教えて頂けますでしょうか
以下のログを見ると、customize/main.py から呼び出していらっしゃる、paramiko パッケージの paramiko.client.SSHClient クラスの connect() の中で、socket.connect() の呼び出しが 101 (: ENETUNREACH) の OSError になって例外送出しているようですね。
>set_command sleep infinityだけのコンテナ内に入って実行した場合は、何回やってもエラーが出ません。
とのことですが、以前のコメントで書いていらしたのと同じ待ち動作を入れると、どうなるでしょうか？
https://armadillo.atmark-techno.com/forum/armadillo/17845#comment-14819
このコメントと同様な待ち動作を再び行うようにすると問題ない場合は、LTE 接続が確立するより前に SSH サーバーへの接続が行われてしまう時があるのが原因だと思います。
>------------------------------
>armadillo:~# podman logs a6e-gw-container
>ssse-flw: EmbSe_Init(): Entry
>App :INFO :Using PortName='/dev/i2c-1:0x48' (ENV: EX_SSS_BOOT_SSS_PORT=/dev/i2c-1:0x48)
>sss :INFO :atr (Len=35)
> 00 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 08
> 01 00 00 00 00 64 00 00 0A 4A 43 4F 50 34 20 41
> 54 50 4F
>sss :WARN :Communication channel is Plain.
>sss :WARN :!!!Not recommended for production use.!!!
>ssse-flw: Version: 1.0.5
>ssse-flw: EmbSe_Init(): Exit
>ssse-flw: Control Command EMBSE_LOG_LEVEL; requested log level = 4
>Traceback (most recent call last):
> File "/root/gw_container/customize/main.py", line 88, in
> client.connect(hostname=host, username=host_username, password=host_password, timeout=10, look_for_keys=False)
> File "/usr/lib/python3.11/site-packages/paramiko/client.py", line 365, in connect
> sock.connect(addr)
>OSError: [Errno 101] Network unreachable
ところで、
>>https://armadillo.atmark-techno.com/blog/11167/17337
>>電波状況を見て接続の確認をすることとしました。
> mm_modem = MMModem()
> m = mm_modem.signal_quality()
と書いていらっしゃいますが、mm_modem.signal_qualtiy() の値は、単に取得しているだけでしょうか？あるいは、値を見て、電波状況が悪いと判断した場合は、電波状況が良くなるまで待ってから接続するような実装をしていらっしゃるのでしょうか？
いずれにせよ、最初に接続する前にチェックするだけですと、接続後に電波状況が悪化して通信が途切れると、そこでプログラムが異常終了してしまうのではないかと思います。
より確実な方策は、最初に接続する際に接続エラーの例外送出が起きたら try/except で例外を拾い、接続エラーした場合は、接続できるまで、少し待ってから接続をリトライする動作を繰り返すようにして（※リトライ回数の上限を決めて、上限に達したらエラー終了する、などの対応は入れる方が良いと思いますが）、さらに、接続できた後も、通信中にネットワーク接続が切れてエラーの例外送出が起きた時に、その例外を拾って再接続するような動作を入れることだと思います。
https://armadillo.atmark-techno.com/forum/armadillo/17845#comment-14824
uen2825
古賀様
ありがとうございます。
1回目（うまくいった場合）の最後にsys.exit()を入れたところ希望通りの動作になりました。
> より確実な方策は、最初に接続する際に接続エラーの例外送出が起きたら try/except で例外を拾い、接続エラーした場合は、接続できるまで、少し待ってから接続をリトライする動作を繰り返すようにして（※リトライ回数の上限を決めて、上限に達したらエラー終了する、などの対応は入れる方が良いと思いますが）、さらに、接続できた後も、通信中にネットワーク接続が切れてエラーの例外送出が起きた時に、その例外を拾って再接続するような動作を入れることだと思います。
今後こちらの対応をする予定です。
別件で申し訳ございません。
SLEEPモードにした場合、SLEEP状態からの起動はコンテナ内の処理を終了してから終わっているようですが
電源OFF状態から起動すると、起動途中で停止してしまう状況です（50秒くらいのところ）。SWを押すと続きから動くような感じです。
電源OFF状態から途中停止しないよう起動させたいのですが、どのような設定をしたらよいでしょうか。
koga
アットマークテクノの古賀（休日モード）です。
uen2825さん：
>別件で申し訳ございません。
>SLEEPモードにした場合、SLEEP状態からの起動はコンテナ内の処理を終了してから終わっているようですが
>電源OFF状態から起動すると、起動途中で停止してしまう状況です（50秒くらいのところ）。SWを押すと続きから動くような感じです。
>電源OFF状態から途中停止しないよう起動させたいのですが、どのような設定をしたらよいでしょうか。
確認ですが、現在の設定では、
/etc/containers/aiot_gw_container_hooks.d/hook.sh
で何を行うようにしていらっしゃるでしょうか？
もし、コンテナ終了をトリガーとして sleep する設定にしていらっしゃるのであれば、電源 OFF 状態から起動した時には LTE 接続が確立する前にプログラムがサーバーへ接続しようとしてエラーしてしまい、その結果、プログラムが強制終了してコンテナが終了して sleep しているのかも知れません。
sleep 中に SW1 を押すと、sleep から起床しますし、コンテナ終了をトリガーとして sleep する設定にしている場合、sleep から起床したのち、atmark-power-utils サービスがコンテナを自動起動します。
ですので、もし、コンテナ終了をトリガーとして sleep する設定にしていらっしゃるのであれば、電源 OFF 状態から起動した時の動作では、プログラムがサーバーへ接続しようとしてエラーした際に、リトライ動作せずに終了するのが要因ではないかと思います。もしそうであれば、以下の対応を加えて頂くことで問題を解消できると思います。
>>より確実な方策は、最初に接続する際に接続エラーの例外送出が起きたら try/except で
>>例外を拾い、接続エラーした場合は、接続できるまで、少し待ってから接続をリトライ
>>する動作を繰り返すようにして（※リトライ回数の上限を決めて、上限に達したら
>>エラー終了する、などの対応は入れる方が良いと思いますが）、さらに、接続できた後も、
>>通信中にネットワーク接続が切れてエラーの例外送出が起きた時に、その例外を拾って
>>再接続するような動作を入れることだと思います。
>
>今後こちらの対応をする予定です。
以上、ひとまずのコメントです。
uen2825
古賀様
お世話になっております。
下記の処理を入れて対応したところ希望する動作になりました。
ありがとうございました。
> >>より確実な方策は、最初に接続する際に接続エラーの例外送出が起きたら try/except で
> >>例外を拾い、接続エラーした場合は、接続できるまで、少し待ってから接続をリトライ
> >>する動作を繰り返すようにして（※リトライ回数の上限を決めて、上限に達したら
> >>エラー終了する、などの対応は入れる方が良いと思いますが）、さらに、接続できた後も、
> >>通信中にネットワーク接続が切れてエラーの例外送出が起きた時に、その例外を拾って
> >>再接続するような動作を入れることだと思います。
uen2825
お世話になっております。
使用中のバージョン等です
Kernel 5.10.205-0-at
3.18.5-at.8
現在連続運転中なのですが、sleepモードで実行中、電波状態が0で接続できないことがあります。
その後sleepでの接続が出来なくなってしまいます。電波状態が０のままです。
一度A6Eの電源を落とすと繋がるようになります。
電場状態を拾ってくるパイソンプログラムです
from mm_dbus_modem import MMModem
mm_modem = MMModem()
Condition = mm_modem.signal_quality()
電波状態が一定数値以上になるまでリトライを掛けています。
そこでお聞きしたいのが
1.aiot-sleepモードになっている事を確認する方法はありますか
2.LTE-Mをリセットする方法はありますか
宜しくお願いいたします。
uen2825
koga
2023年11月24日 8時46分
アットマークテクノの古賀です。
uen2825さん：
>LTE接続でコンテナ起動した場合、通常は問題なく接続できます。
>コンテナ終了時に電源を落とす設定にすると、自動起動するプログラムに行く前に落ちてしまいます。
> /etc/containers/aiot_gw_container_hooks.d/hook.shに/sbin/poweroffを追加
>LAN接続の場合どちらも正常に動作します。
>どこかでLTE接続までのタイムアウトを設定できるところは無いでしょうか？
いま一つ状況が分からないので、二点確認させてください：
1.) 「コンテナ終了時に電源を落とす設定にすると、自動起動するプログラムに行く前に落ちてしまいます。」とおっしゃっている、「自動起動するプログラムに行く前に」というのは、次のどの状況でしょうか？
1-a.) コンテナ終了をトリガーとして poweroff した後、AC アダプタを抜き差しするなどして Armadillo に電源を投入し直し、起動した際の、自動起動する設定のコンテナが起動する際の挙動（コンテナが実行するプログラムの初期化処理でエラーする）。
1-b.) それ以外。
(1-b) の場合は、もう少し詳しい状況を教えてください。
2.) 「LTE接続でコンテナ起動した場合、通常は問題なく接続できます。」とおっしゃっている「通常は」というのは、(1) で「落ちてしまう」場合と、どのようにプログラム起動順序が違うのでしょうか？手順の違いを教えてください。
以上、「LTE 接続までのタイムアウト設定」に対する回答ではなく恐縮ですが、取り急ぎ状況を確認したく思い質問です。
お手数をかけますが、どうぞ宜しくお願いします。