#はじめに
3度目ですが、Greengrass(V1)のOTAアップデートの記事です。
依然として根本的な問題解決ではないものの、問題の再現/回避ができるようになったので備忘録としてまとめておきます。
まず、以下の記事でGreengrassのOTAアップデートを実施した際、Lambdaが動かない＋グループのデプロイが出てこない問題が発生しました。
参考：Greengrass(V1)のOTAアップデートを実施する
上記の場合、Greengrassの再起動によってLambda、デプロイ共に問題は解消しました。
そこで、OTAアップデートの後にシェルスクリプトを実行してGreengrassの再起動を行って問題解決しようとしたのが以下の記事です。
参考：Greengrass(V1)のOTAアップデート前後にシェルスクリプトを実行する
しかし、前回の記事内で以下を再度試してみると、Lambda、デプロイの問題はともに発生しませんでした。
- シェルスクリプトから
systemctl restart greengrassを省く（＝Greengrassを再起動しない） - （上記で問題が再現しなかったので）シェルスクリプトを使わない方式でOTAアップデートを再度行う
なぜ上記のようになったか、再現自体はできたので以下にまとめていきます。
#1 今回の検証方法
今回は4つのシナリオを用意して、最終的に以下を確認しました。
- OTAアップデート後にLambdaが動く
- 5秒おきにメッセージを送るLambdaをコアデバイスにデプロイ済
- OTAアップデート後にグループのデプロイができる
なお、この検証もGreengrassをインストールしたJetson nanoで実施しています。
##1-1 検証シナリオ
以下の通りシナリオを作成ました。
要素としては以下の2つです。
###①Coreの更新前にOTAエージェントを更新するか
問題が発生しなかった際は、単純にCoreのOTあアップデートのみを行っていました。
そのため、Coreのアップデート前にOTAエージェントのアップデートを行うことで影響があるか検証します。
###②OTAエージェントをフルパスで実行するか
OTAエージェント実行時、問題が発生した際はAWSの公式ドキュメントに従って以下の通りコマンドを実行しました。
cd /greengrass/ota/ota_agent
sudo ./ggc-ota
一方で、前回はsudo /greengrass/ota/ota_agent/ggc-otaとフルパスで実行しています。
この点が影響するかも検証します。
##1-2 補足・フルパス実行になぜ注目するか
Greengrass Core、OTAエージェント共に、プロセスを見ると以下のような表示となります。
#Greengrass Coreのプロセス表示
ps aux | grep -E "greengrass.*daemon"
root 12571 0.0 0.0 6696 660 pts/0 S+ 20:25 0:00 grep --color=auto -E greengrass.*daemon
root 18624 11.3 0.9 1673976 37224 ? Sl 20:04 2:19 /greengrass/ggc/packages/1.11.0_12/bin/daemon -core-dir /greengrass/ggc/packages/1.11.0_12 -greengrassdPid 18600
#OTAエージェントのプロセス表示
ps aux | grep ota
root 4055 0.0 0.1 78868 4572 ? Ssl 18:58 0:00 /greengrass/ota/ota_agent_v1.0.0_11/ggc-ota -p 28945
root 16769 0.0 0.0 6696 664 pts/0 S+ 20:25 0:00 grep --color=auto -E ota
パスの一部に1.11.0_*、ota_agent_v1.0.0_*とあり、この*箇所がOTAアップデートの度にインクリメントされます。
そして、OTAエージェント起動のために実行するコマンドsudo /greengrass/ota/ota_agent/ggc_otaのパスに含まれるディレクトリota_agentがシンボリックリンクとなっており、最新バージョンのディレクトリを見ているようです。
ls -ld /greengrass/ota/ota_agent
lrwxrwxrwx 1 root root 22 3月 18 18:58 /greengrass/ota/ota_agent -> ./ota_agent_v1.0.0_11/
ota_agentディレクトリに移動して、その配下で直接sudo ./ggc_otaと実行した場合、OTAエージェントのバージョン（またパス）が変わると何らかの影響があるかもしれない…ということで検証シナリオに含めています。
#2 検証結果
以下の結果となりました。
OTAアップデート後にLambda、デプロイでエラーが出るのは以下の場合と考えられます。
- OTAエージェントを実行する際
/greengrass/ota/ota_agentに移動し、sudo ./ggc_otaという順で実行している - CoreのOTAアップデート前にOTAエージェントのアップデートを実施している
##2-1 発生したエラー
今回はLambdaの実行状況とグループのデプロイができるかを確認しています。
###Lambdaの実行状況
常時実行しているLambdaからのメッセージをサブスクライブしたものの、メッセージが届かなくなっていました。
また、IoT Coreからのメッセージで駆動するLambda（IoT Coreにメッセージを返す）にメッセージを発行したものの、メッセージは返ってきませんでした。
なお、/greengrass/ggc/var/log/user/[リージョン名]/[アカウントID]/[関数名].logを確認すると・・・
- 常時実行のLambdaはOTAアップデートのタイミングでログの書き込みが止まっていた
- メッセージ駆動のLambdaはメッセージを送ったタイミングでもログに書き込みが行われていなかった
Lambdaの実行時ではなく、その前段で問題があるだろうことが分かる。
※残念ながら今回はそこまでは突き止められておらず・・・
###グループのデプロイ
グループをデプロイすると以下のエラーメッセージが確認された。
Deployment xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx of type NewDeployment for group xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx failed error: runtime execution error: unable to initialize container configuration for lambda: getwd: no such file or directory
##2-2 補足・OTAエージェントのアップデート後のパス
OTAエージェントのアップデート後に、OTAエージェントのパスがどうなっているか確認してみました。
#OTAエージェントのアップデート前
ps aux | grep ota
root 28945 3.0 0.0 78760 3940 ? Ssl 18:57 0:00 ./ggc-ota
root 29423 0.0 0.0 6696 636 pts/0 S+ 18:57 0:00 grep --color=auto ota
#OTAエージェントのOTAアップデート後
ps aux | grep ota
root 4055 0.5 0.1 78868 4456 ? Ssl 18:58 0:00 /greengrass/ota/ota_agent_v1.0.0_11/ggc-ota -p 28945
root 7775 0.0 0.0 6696 624 pts/0 S+ 18:58 0:00 grep --color=auto ota
上記は./ggc-otaで実行した場合の例ですが、フルパスで実行した際もアップデート後は同様に表示されました
また、前回の記事でOTAアップデートの前後にシェルスクリプトを実行するよう設定した際、Greengrassの停止→開始は必須だったものの、OTAエージェントについてはそうした処理は必須ではありませんでした。
しかし、上記の通りPIDが変わっているので、OTAエージェントが自身で再起動をしているのだと思います。
※AWS公式ドキュメントにもそのようなことが書かれています。
は独自のプロセスを管理するため、OTA 更新エージェント および ota_pre_update.sh スクリプトが OTA サービスを停止または開始する必要はありません。ota_post_update.sh
出典：init システムとの統合
#3 おわりに
簡易的な検証ですが、いったんはOTAアップデート時に問題が発生するパターンを整理できました。
ただ、今回も本質的な解決や原因究明ではありませんが・・・
記事名の通り「備忘録」として残しておきます。