my db was getting way too large (mysql), so i stopped hass and truncated the tables. i’ve been waiting for what seems like hours now waiting for the gui to come back up…how long should this take? i’m tailing the daemon log and i can see that envisalink keeps sending a zone update every 30 seconds which hass is recording, so it seems to at least be running…but no gui.
The normal way to do this is to use the purge_keep_days parameter.
If you haven’t changed the code, and the database is OK, HA should start as a regular startup, in a minute or two depending on your configuration and hardware.
Since it hasn’t, I expect the DB is not OK, and unless you are absolutely desperate to keep the history, the sensible thing is to delete the database and start again.
i was on an old version that was prior to purge_keep_days, that’s why i wasn’t using it. i tried multiple times deleting the db, even switching back to sqlite from mysql…no dice.
it seems the issue is somehow with my custom fork of the ecobee api…i upgraded to the most recent version and that brought everything back, until i tried to link in my custom api again. now it again won’t start the GUI.
what confuses me is how this ended up breaking anything in the first place. it was working just fine and i hadn’t upgraded anything when i deleted the db, so i’m not sure what changed.
…and now when trying to go back to the included deps, i still can’t get the ui to load. ugh. i have no clue what broke this, and that’s so incredibly frustrating…it was working flawlessly for over a year.
it seems the only way i can get the gui to reload now is to reboot the pi. just stopping/starting or restarting the service leads to the gui not loading, every single time…
You need to check the logs (sudo journalctl -f -u home-assistant@homeassistant) and find out what the problem is.
There are many potential issues.
i have been looking at the logs the entire time, i don’t see anything out of the ordinary. it basically just hangs with no indication of what’s wrong…the only thing that keeps coming through in the logs is a zone update from envisalink every 30 seconds.
this is the only thing that looks strange to me…
Jan 09 10:23:03 hassbian systemd[1]: [email protected] stop-sigterm timed out. Skipping SIGKILL.
Jan 09 10:24:33 hassbian systemd[1]: [email protected] stop-final-sigterm timed out. Skipping SIGKILL. Entering failed mode.
Jan 09 10:24:33 hassbian systemd[1]: Unit [email protected] entered failed state.
this coincides with it taking FOREVER to restart hass when doing it via service stop/start (in addition to the fact that it never brings the gui back up). prior to this it would only take a few seconds to restart it…
edit: it seems like this is the underlying issue. when i restart via service calls, there are now two instances running. if i kill -9 the first instance before starting via service, the gui starts up fine.
I’ll have to admit that I find the service calls a bit hit and miss, and always restart with systemctl on the command line.
same thing with systemctl.
sudo systemctl restart [email protected] is the command i just used, and same issue. either way it’s strange, i’ve always used service calls to restart and never had a single issue before yesterday…
Do you use Envisalink ?