tomspark wrote:
You're right, and that's my miss — docker stop alone won't hold, because deunhealth is set to always-restart and SparkBox also recreates it on the next sparkbox up or update. Removing it (docker rm sb-deunhealth) is the right move for now. One heads-up: it'll come back the next time you update or run sparkbox up, so you may need to remove it again until the real fix lands. Removing it is safe in the meantime — the only thing you give up is the automatic restart of a genuinely-stuck container, and on your hardware that watchdog was the thing causing the loop, so you're better off without it for now. The proper fix (much longer boot grace so it stops misfiring on slower boxes) is queued — once it ships you can let deunhealth run normally again. Thanks for the precise follow-ups, they're genuinely useful.
tomspark wrote:
Great diagnosis — you've nailed it. On a 2-core ARM box those apps take longer to finish their first boot than our health-check grace allows, so they get flagged unhealthy mid-startup and the watchdog (deunhealth) restarts them before they're ready — exactly the loop you're seeing. Your docker stop sb-deunhealth workaround is a totally safe way to get up and running in the meantime: it only turns off the auto-restart-on-unhealthy watchdog, nothing else. The real fix is giving those containers a lot more boot grace on slower hardware, which I'm putting in now — it'll land in an update shortly, and then you can leave deunhealth on. Thanks for pinning down the hardware and the exact symptom; that's precisely what I needed. (I also noted the blank 'Share to Demox' box — looking at that one separately.)
paulrturnbull wrote:
Thanks Tom, Workaround: docker stop sb-deunhealth didn't actually work. it restarted itself. Workaround: docker update --restart=no sb-deunhealth && docker stop sb-deunhealth this actually stopped the watchdog