Open pdcastro opened 4 years ago
[pdcastro] This issue has attached support thread https://jel.ly.fish/#/support-thread~f84739ea-4bb1-4387-baa5-b8459ce7d5d6
[lucianbuzzo] This issue has attached support thread https://jel.ly.fish/2567905c-cd9d-42e4-bb8b-66e9eab11adb
A user has reported the same issue on the following device: Device type: Raspberry Pi 3 OS version: balenaOS 2.47.0+rev1 Supervisor version: 10.6.27
Here is the log output https://gist.github.com/Roger/b82a219489a73552392bc6764868c99f
[kaisoz] This issue has attached support thread https://jel.ly.fish/00eb50cb-124a-4d7d-a27e-d9e2e08d4d6a
I've seen this error happening also on this device:
Application url: https://dashboard.balena-cloud.com/apps/1053081 Device URL: https://dashboard.balena-cloud.com/devices/429d927a405d2142400cf2ccff9f8b63 Device type: Raspberry Pi 3 OS version: balenaOS 2.47.0+rev1 Supervisor version: 10.6.27
User shared a 2.44.0+rev1 Intel NUC device where balenaEngine was failing to start with errors including
"dial unix \x00/containerd-shim/moby/0a3da4c.../shim.sock: connect: connection refused",
among several others. See log excerpts below; full"journalctl -au balena"
logs are attached to the support issue (JF link in a comment).Restarting services was not sufficient to recover the device. The solution described in issue #186 was attempted in order to recover the device, but it did not help. (To be clear, balenaEngine was already failing to start before the solution described in #186 was attempted.)
It looks like DNS lookup was failing, and leading to the image pull failing:
That's most likely why the application update wasn't working. What happens after that is summarised in these logs:
... which eventually leads to balenEngine being SIGABRT'd by the healthdog
After that, containerd/engine won't come back healthy: