Armadilloフォーラム

SLEEPモードに遷移しなくなってしまいました

uen2825

2024年3月27日 11時14分

お世話になっております。
製品アップデートしたところ
baseos-6e-3.18.5-at.8.swu ⇒ baseos-6e-3.19.1-at.2.swu
SLEEPに遷移しなくなってしまいました。
a6e-gw-container.confからpythonプログラムを実行し、終了する際は sys.exit() で抜けています。
条件によってSLEEPかシャットダウンしています。
/etc/containers/aiot_gw_container_hooks.d/hook.sh ⇒添付ファイル参照ください
SLEEP設定
/etc/atmark/power-utils.conf ⇒添付ファイル参照ください
製品アップデートにより何かしら変更が必要なのでしょうか。
ご指導いただけますよう、宜しくお願いいたします。

ファイル ファイルの説明
hook.sh
power-utils.conf
コメント

アットマークテクノの古賀です。

uen2825さん:
>製品アップデートしたところ
>baseos-6e-3.18.5-at.8.swu ⇒ baseos-6e-3.19.1-at.2.swu
>SLEEPに遷移しなくなってしまいました。
>a6e-gw-container.confからpythonプログラムを実行し、終了する際は sys.exit() で抜けています。
>条件によってSLEEPかシャットダウンしています。
>/etc/containers/aiot_gw_container_hooks.d/hook.sh ⇒添付ファイル参照ください
>SLEEP設定
>/etc/atmark/power-utils.conf ⇒添付ファイル参照ください
>製品アップデートにより何かしら変更が必要なのでしょうか。

こちらでは、上記アップデートによる問題は再現しません。
製品アップデートのリリース前のテストでも異常ありませんでしたが、念のため、先ほど以下の手順でアップデートして確認しました。
アップデート後も、コンテナ終了をトリガとして問題なく SLEEP モードに遷移します。

1.) Base OS 3.18.5-at.7 のインストールディスクイメージで初期化
  初期化後、コンテナ終了で SLEEP モードへ遷移するように /etc/atmark/power-utils.conf の内容を書き換えて、persist_file により変更内容を永続化

2.) baseos-6e-3.18.5-at.8.swu を適用して 3.18.5-at.8 にアップデート

3.) baseos-6e-3.19.1-at.2.swu を適用して 3.19.1-at.2 にアップデート

確認ですが、コンテナで動かしていらっしゃる python プログラムが終了しても SLEEP していない状態で、Base OS のシェルで以下の
コマンドを実行すると、どういう出力になるでしょうか?

armadillo:~# podman ps -a

古賀様
ご回答ありがとうございます。

> 確認ですが、コンテナで動かしていらっしゃる python プログラムが終了しても SLEEP していない状態で、Base OS のシェルで以下の
> コマンドを実行すると、どういう出力になるでしょうか?
下記の様になりました。
更新時間が30分前ですが、コンテナ内で自動での起動をストップ/スタートを変更したためです。

CONTAINER ID  IMAGE                              COMMAND               CREATED             STATUS                     PORTS       NAMES
0f8890fef791  localhost/a6e-gw-container:v2.4.0  python3 /root/gw_...  About a minute ago  Exited (0) 30 seconds ago              a6e-gw-container

初期状態に戻して、再度バージョンアップしてみたいと思います。

お世話になっております。
以前下記アップデートしてSLEEPに遷移しなくなってしまったと相談させていただきました。
baseos-6e-3.18.5-at.8.swu ⇒ baseos-6e-3.19.1-at.2.swu
その後初期状態にして再度バージョンアップしても遷移しない状況でした。
今回新たなアップデートがありましたので更新しました
baseos-6e-3.18.5-at.8.swu ⇒ baseos-6e-3.19.1-at.3.swu
電源オフ状態からの起動は上手くいっているようですが、SLEEPに遷移しません。
1.A6E電源オフ状態からRS485受信で起動しました
2.コンテナ内のpythonプログラム実行しました。処理終了後sys.exet()で終了。
  (podman logs a6e-gw-conteinaerでsys.exetを通った事を確認しました)
何か設定確認するところがありましたらご指導いただけないでしょうか
宜しくお願いいたします。

ファイル ファイルの説明
a6e-gw-container.conf

at_reika.yamazaki

2024年4月24日 19時18分

お世話になっております。
山崎です。

お使いの conf ファイルの添付ありがとうございます。
こちらの conf ファイルを利用したところ、 SLEEP 移行しない現象が再現できました。
conf ファイルを確認したところ、以下の行をコメントアウトすると SLEEP 移行に成功することがわかりました。

#add_volumes /var/app/volumes/usb:/usb:shared
#add_volumes /mnt:/mnt:shared

また、add_volumes ですが、以下の使い方になります。

add_volumes <マウント元>:<コンテナ内のマウント先>:<オプション>

オプションでは以下が指定可能です。
ro : read-only
rw : read-write
z : 共有ラベルへの変更
詳細は以下をご確認ください。
https://docs.podman.io/en/v4.4/markdown/options/volumes-from.html

上記を参考に shared の個所を変更して、改善されるかどうかご確認いただけますと幸いです。

以上、どうぞよろしくお願いいたします。

山崎様
大変お世話になっております。
ご指摘いただいた内容に変更したところ動作いたしました。
USB接続するメモリ、カメラも動作できることを確認しました。
早急なご回答ありがとうございました。

at_dominique.m…

2024年4月25日 10時21分

よこからすみません、
マルティネです。

原因の解析としては問題ありませんが、今回は使用不可能なオプションではなく、podman の不具合なので一つを訂正させてください。

山崎さんが説明してくれた使用可能なオプションは「--volumes-from」の場合のオプションですが、add_volumes は「--volume」なので podman のオプションとしてはこちらです:
https://docs.podman.io/en/v4.4/markdown/options/volume.html

なので、shared でも使えますが、今回は /sys のマウントとコンテナ停止フックの処理の詳細で不具合が発生して、shared のマウントを使うとフックがコンテナ停止時ではなく、podman rm で削除するときに実行されてしまうようになります。

詳細としては、/sys 全てが問題ではなく、コンテナ停止時に /sys/fs/cgroup にあるコンテナの cgroup 領域を削除しようとしてますが、shared の場合は「EBUSY」でエラーして削除処理ができないところでフックの実行を後回しにするようになっています。
その処理はコンテナのマウントネームスペースで実行されていて、cgroup をマスクすれば再び正常に動きます。以下の行をコンテナのコンフィグに追加していただければ、shared のボリュームも使用しても SLEEP 動作が再びできるようになります:

add_volumes /var/empty:/sys/fs/cgroup:ro

(shared オプションは結局不要だった場合は、shared 無しでこのワークアラウンドも不要なので、このままお使いください)

長い面では、この cgroup の処理はそこでやらなくてもいいと思いますので、podman の開発者にも報告して直すようにしておきますが、このワークアラウンドで問題がありませんので修正を待たなくていいと考えています。
不具合報告、大変ありがとうございました。

よろしくお願いします。

at_dominique.m…

2024年4月25日 13時40分

連続ですみません、
マルティネです。

アップストリームへの修正の報告です。

> 長い面では、この cgroup の処理はそこでやらなくてもいいと思いますので、podman の開発者にも報告して直すようにしておきますが、このワークアラウンドで問題がありませんので修正を待たなくていいと考えています。

こちらは結局 podman ではなく crun の不具合でした。
crun 1.9.1 に入った https://github.com/containers/crun/commit/523eed3f0f4b3ba59f002fae3fb95… のエラー処理の問題です。
https://github.com/containers/crun/pull/1456 で修正までできて、せっかくなので 5月のアップデートにも入れようと思います。

問い合わせに書いてくれたように、ABOS 3.18.5-at.8 では crun 1.8.4 が使われていますので、そちらでは問題がまだなかったです。

よろしくお願いします。