#cloudflared getting Killed regularly after last update.
1 messages · Page 1 of 1 (latest)
yeah I would think that a ram issue killing the addon is likely. a rpi3 is pretty old by this point.
no way to rollback an addon is there?
odd that the watchdog doesn't restart it, but i suppose since it's likely ram related, that makes some sense.
if you have a backup that includes the addon then you can do a partial restore of just the addon.
oh interesting, i think it's an unhandled bug
cloudflared got killed... while i was watching the ram not do anything (80%) ... and got a dump of the cloudflare 502 error on the client's cloudflared log
i guess that's not indicative so much as probably symptomatic though
"The web server reported a bad gateway error."
i suppose dmesg would be the next thing to check
also see if there's anything in the supervisor logs when the addon dies as its the container orchestrator for it. maybe something might give a hint there.
i haven't seen anything in any logs anywhere that hint why it's being killed
not sure if i can ssh in though?
there are ways of enabling ssh to the host system but in general its not overly recommended. plugging in a monitor and keyboard is often the quickest way to get to the host system shell. from the HA-CLI thats running by default you can type login and it will drop you to a root shell.
supervisor log just says "warning cloudflared is failed"
2025-12-26 12:36:58.859 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon Cloudflared is failed, restarting...
"Host" logs seem to take forever to load
and nothing in the cloudflared addons logs? it would seem that the problem is likely in there. if the supervisor isn't killing it then its either dying itself or something else is causing it to fall over (in which case dmesg might be the way to investigate)
correct
i'm gonna restart cloudflared to try and get a proximal time to when it dies
I realize this is probably a "time for new hardware" issue, but I haven't really found proof of that yet.
plus shipping time etc lol
I think it likely indeed is yeah but I do see your point.
it could be your boot/data media I guess? what are you using for storage?
you would get the proof after installing it as vm on a small pc running proxmox. Speeds and overall handling / ux would make you smile at least instantly, compared to pi3
pi3 is maxed out at some point
i don't have any proof that the pi3 is maxxed here, causing this issue
worked perfectly for months and suddenly 7.0.1 comes out and it won't stay up for 10m
does not have to be right now, but it's just not future proof. was more about the first part, the user experience 😉
well, it seems i've cured the issue
maybe speaking too soon
but...
i finally "rebooted the system" instead of "restarting HA" (which i thought was a reboot
hasn't had an issue since.
"restart home assistant" only restarts the core container.
hardware reboot to restart os/supervisor can definitely solve some issues form time to time.
hopefully problem is resolved in any case 🙂
although a hardware update is probably something you should do sooner rather than later tbh.
@dusky palm fyi, i believe i have identified it. I had added Matter near the time of the update. it utilizes 400MB of ram. that's a lot for a 1GB pi3b.
i killed off matter and pulseaudio and saved half my available ram. rock solid again
Cool, You really should try and move to something with more ram as soon as is practical.
it's kinda funny... i unexpectedly allocated 40% of my ram to something i didn't use. I did buy a NUC so ...
but really, unless i need Matter for something, i've got a decent margin yet. :D >_< silliness
the real problem was that I wasn't really given good indications that i had exhausted my RAM, until i got in and checked the linuxy bits like dmesg
from the UI, just "Killed"