Развертывание Greengrass застряло на "В процессе" - PullRequest
0 голосов
/ 18 января 2019

Я пытаюсь настроить группу AWS Greengrass через их JavaScript SDK, и я все готово и работаю там, где у меня развертывание. Проблема в том, что развертывание, похоже, застряло "в процессе", и нет журналов CloudWatch, которые бы мне помогли.

Я посмотрел на основное устройство, и вот что я увидел в файле /greengrass/ggc/var/logs/system/runtime.log:

[2019-01-18T03:17:22.64Z][INFO]-Greengrass Root: /greengrass
[2019-01-18T03:17:22.64Z][INFO]-Greengrass Write Directory: /greengrass/ggc
[2019-01-18T03:17:22.64Z][INFO]-Group File Directory: /greengrass/ggc/deployment/group
[2019-01-18T03:17:22.64Z][INFO]-Default Lambda UID: 498 GID: 496
[2019-01-18T03:17:22.64Z][INFO]-===========================================
[2019-01-18T03:17:22.64Z][INFO]-The current core is using the AWS IoT certificates with fingerprint: 7591dcd10e96f86dd2d323d468b84b419b26280bbcfd3c0eee45c5a12c6d2dd7
[2019-01-18T03:17:22.641Z][WARN]-worker process info: /greengrass/ggc/packages/1.7.0/var/worker/processes
[2019-01-18T03:17:22.641Z][WARN]-worker process info: /greengrass/ggc/packages/1.7.0/var/worker/processes
[2019-01-18T03:17:22.641Z][INFO]-Reloading registry
[2019-01-18T03:17:22.642Z][INFO]-The current core is using the AWS IoT certificates with fingerprint: 7591dcd10e96f86dd2d323d468b84b419b26280bbcfd3c0eee45c5a12c6d2dd7

Я проверил и смог успешно подключиться к конечной точке ATS, используя OpenSSL и имеющиеся у меня сертификаты. Я использую рекомендованный сертификат Amazon из учебника Greengrass RSA 2048-битный ключ: Amazon Root CA 1.

Какие диагностические шаги или подсказки, куда идти дальше?

Ответы [ 2 ]

0 голосов
/ 18 января 2019

Так что для меня было неправильно настроено 2 вещи, которые помешали успешному развертыванию

  1. Развертывание застряло «в процессе», поскольку для прикрепленных разрешений в политике и роли требовались лямбда-разрешения для развертывания. После этого развертывание перешло от «в процессе» к «неудачному развертыванию», что привело меня ко второй ошибке.

  2. Экземпляр EC2, на котором размещалось основное программное обеспечение, почему-то неправильно выполнял сценарий оболочки установки (вероятно, не запускал его как sudo), и мои cgroups не были полностью настроены на память (не уверен, что это означает но вам нужно это настроить)

Спасибо, Стив Б, за помощь!

0 голосов
/ 18 января 2019

У меня была эта проблема раньше. Я полагаю, что это просто ошибка, из-за которой внутренности портятся из-за плохого развертывания.

Способ, которым я использую принудительное развертывание, заключается в создании нового ядра, а затем добавлении известных рабочих lamdbas в рабочей группе к новому ядру, уничтожении и перезапуске демона на основном устройстве, а затем повторном развертывании.

...