はじめに

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アップデート時に問題が発生するパターンを整理できました。
ただ、今回も本質的な解決や原因究明ではありませんが・・・

記事名の通り「備忘録」として残しておきます。