【備忘録】Greengrass Core(V1)をOTAアップデートした後に不具合が発生するパターンの検証

#はじめに
3度目ですが、Greengrass(V1)のOTAアップデートの記事です。
依然として根本的な問題解決ではないものの、問題の再現/回避ができるようになったので備忘録としてまとめておきます。

まず、以下の記事でGreengrassのOTAアップデートを実施した際、Lambdaが動かない＋グループのデプロイが出てこない問題が発生しました。
参考：[Greengrass(V1)のOTAアップデートを実施する](https://qiita.com/kt-yt/items/b4ceaca58757c5bab225)

上記の場合、Greengrassの再起動によってLambda、デプロイ共に問題は解消しました。
そこで、OTAアップデートの後にシェルスクリプトを実行してGreengrassの再起動を行って問題解決しようとしたのが以下の記事です。
参考：[Greengrass(V1)のOTAアップデート前後にシェルスクリプトを実行する](https://qiita.com/kt-yt/items/0626b568d5b4f8d2483d)

しかし、前回の記事内で以下を再度試してみると、Lambda、デプロイの問題はともに発生しませんでした。

* シェルスクリプトから`systemctl restart greengrass`を省く（＝Greengrassを再起動しない）
* （上記で問題が再現しなかったので）シェルスクリプトを使わない方式でOTAアップデートを再度行う

なぜ上記のようになったか、再現自体はできたので以下にまとめていきます。
#1　今回の検証方法
今回は4つのシナリオを用意して、最終的に以下を確認しました。

* OTAアップデート後にLambdaが動く
 * 5秒おきにメッセージを送るLambdaをコアデバイスにデプロイ済
* OTAアップデート後にグループのデプロイができる

なお、この検証もGreengrassをインストールしたJetson nanoで実施しています。
##1-1　検証シナリオ
以下の通りシナリオを作成ました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1001693/0d375285-4f09-eb83-8f74-53d43ab80bc5.png)
要素としては以下の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　検証結果
以下の結果となりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1001693/e1ec359e-a73e-7c25-c5d2-93dec5a87f9b.png)
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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1001693/119412e2-930d-11b8-6ec7-5ca783eb857a.png)

##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 システムとの統合](https://docs.aws.amazon.com/ja_jp/greengrass/v1/developerguide/core-ota-update.html#integration-with-init)

#3　おわりに
簡易的な検証ですが、いったんはOTAアップデート時に問題が発生するパターンを整理できました。
ただ、今回も本質的な解決や原因究明ではありませんが・・・

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