I have noticed that hassio on raspberry pi 3 has been resetting after approx 1 day. Longest I have had is 1.5 days. Anyone else noticing this? How do I trace what is making it restart?
I first noticed this as some generic thermostats were getting set to initial values at random times.
All that shows in the log is that the recorder has ended an unfinished session. I assume this is when it starts the new session after the restart.
mine stays up basically forever, i.e. I’ve never seen it go down once up and running. Caveat: Given that I am in there routinely mucking around in configuration.yaml and restarting hassio I probably haven’t ever left it up on its own for more than a month at most.
I just found the hassio supervisor logs, 8:36 has a message, does this give any clues as to what is wrong?
18-10-24 08:21:51 INFO (MainThread) [hassio.homeassistant] Updated Home Assistant API token
18-10-24 08:36:49 WARNING (MainThread) [hassio.tasks] Watchdog found a problem with Home Assistant Docker!
18-10-24 08:36:49 INFO (SyncWorker_12) [hassio.docker.interface] Clean homeassistant/raspberrypi3-homeassistant Docker application
18-10-24 08:36:50 INFO (SyncWorker_12) [hassio.docker.homeassistant] Start homeassistant homeassistant/raspberrypi3-homeassistant with version 0.80.3
18-10-24 08:37:21 INFO (MainThread) [hassio.homeassistant] Detect a running Home Assistant instance
18-10-24 08:56:51 INFO (MainThread) [hassio.homeassistant] Updated Home Assistant API token
As my hassio install restarts almost every day, I think this may be causing my recorder purge to be delayed as it is set to run each day. Isn’t it supposed to call a purge when it restarts if it is behind.
I experienced what you describe and though other issues still happen, I saw no spontaneous restart after installing this temporary workaround (hope its gets updated in the full update soon)
btw, not sure if the watchdog warning is related to the restarts, saw that too, but it didn’t restart after that…
I can confirm that I have changed the power supply and it still does it. May try a new SD card, I am thinking the high endurance ones may be a good option. I may never have noticed this happening and would have thought my system was stable if didn’t use the uptime sensor or set initial values for my generic thermostats.
btw, Ive just updated to the latest beta version 81.0.b2 and wow what an improvement that is, right from the restart.
Feels much much quicker. And, my error counter only goes up to 12… while before I would be happy to see it stop counting at round 40/60 at startup.
Seems the dev’s have done an amazing job weeding out anomalies in this version.
Not sure yet if the binary_ping has been updated also though, so my workaround is still in place.
I could not figure out if I needed to create the directory structure in the config directory or just drop the ping.py file in so for now I have just disabled the ping binary sensors. Hopefully device tracker doesn’t have the same issue. I will see if I can get more than 1.5 days uptime. Maybe the new version will be ready shortly after.
Yep. My uptime was basically permanent (sometimes weeks at a time unless I was adding new automations or making changes). Then it started rebooting every 0.5 to 5 hours. I put hours into troubleshooting this before I stumbled upon the binary_sensors ping issue. I’ve temporarily removed my offending entities for now, but it has me concerned for any future updates. I’ll need to keep a close eye on github issues in future.