If also you experience a huge amount of errors logged by hassio_audio while it attempts to start, then try this solution .
Quickest way to confirm you have this problem is to see if hassio_audio returns a valid date:
# the date in hassio_audio is not set:
docker exec -it hassio_audio date
Sun - 40447 20480:16:-1227370880 -1225953501
# error in hassio_audio logs:
Assertion 'clock_gettime(CLOCK_REALTIME, &ts) == 0' failed
In addition, hassio_audio may cause audio to fail on the host device, and it can also cause an increase in CPU usage, up to 16% on my RPi 4.
Because it is not supported to run Home Assistant without hassio_audio, even when we donāt use it at all, one solution to work around these problems is to suspend PulseAudio running in the hassio_audio container when it is idle, and this can be done by loading the PulseAudio āmodule-suspend-on-idleā module. The shell script described below runs as service and will automatically load the module-suspend-on-idle module when the hassio_audio container is (re)started.
When I updated to latest docker (which Iām not doing lightheartedly again), home assistant container stopped and was not restarted by the watchdog as usual. So I tried with a reboot of the host, at which point I found out that supervisor no longer starts upon boot. Since I also had not restarted the host for a long time, I wasnāt sure if this update or a recent update of the supervisor (usual suspects) or something else was the culprit.I almost destroyed my installation then troubleshooting. Thank God I have portainer, which helps a lot in these situations.
Anyway, back to docker 20.10.3 now and everything works. Lesson to self, if something works do not update. Especially docker (and supervisor, but this is not an option-I canāt understand why).
Only 1 previous docker I remember being a problemā¦ but you do need to keep debian up-to-date and docker will auto-update as part of that.
When I get a docker update I manually restart the supervisor and yesterday I guess I did notice the supervisor and homeassistant container didnāt start but I used portainer (not the addonā¦ yet another reason to use the real portainer to troubleshoot stuff like this). So I did manually start HA and supervisor containers and then in HA I have a script that restarts all my addons so I never rebooted the host anywayā¦ I didnāt think twice about the ha and supervisor not starting when I restarted the serviceā¦ just thought I was impatient and restarted them manually.
If you are running a supervised install you should have the skills to work this out without too many dramas IMO.
My gut feel is that this is a supervisor issue more than a docker issueā¦
Make that two failed updates of docker in a couple of months then. Supervisor is also my first gut feeling in these situations, but I tried with two versions and only when I downgraded docker everything worked.
I also run portainer independently from ha.
IMHO restarts are occasionally needed for general stability but in this case to also emulate loss of power/wifi for our installation. Imagine you were away (without having prepared for that) and there were a power loss, youād think everything worked and ha would never have started, since supervisor would be essentially dead.
So,no, no dramas, just stating the facts with two very recent docker updates and various supervisor updates in the past.
This time is different to the previous time though. Last time, because I never restart the host I didnāt need to roll back docker either FWIW. It seems to me the supervisor service isnāt restarting or starting and even if it started, itās not running the containers but you can manually start them and all is good. So I suspect it will be a supervisor update to fix it but we will see.
I think supervisor is not starting at all this time. Folks are beginning to notice in other threads too, how can we add this to the HA alarms for people to know?
If you ever decide to restart, check your journalctl logs, mine were flooded with docker and various errors, which went away when I downgraded docker. This happens with both latest stable and beta supervisor.
a few weeks ago i installed a debian 10 server , and also installed hassio-supervised.
since a reboot and some network card issues my home assistant doesnt work anymore.
network issues have been fixed for the native site on the server, but iām not familair with docker containers, so troubleshooting this is a pain in the ā¦
who can help me out here. because the things i searched for, dont bring up hassio.
Downgrading docker did the trick for me. Remember to unhold the the packages after the issues has been fixed in HA. Otherwise docker wonāt be upgraded in the future.
Seems the docker issue has identified itās only the docker-cli that is a problem.
I was unable to update supervisor this morning and then supervisor wont auto restart and when it then starts says my system is in an unhealthy state so Iām going to try reverting cli only.
Reverting docker-cli and supervisor immediately self updated, unhealthy state gone again and HA updates. Transcript of session:
david@debian:~$ sudo apt install docker-ce-cli=5:20.10.3~3-0~debian-buster
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be DOWNGRADED:
docker-ce-cli
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Need to get 41.4 MB of archives.
After this operation, 3,072 B disk space will be freed.
Do you want to continue? [Y/n] Y
Get:1 https://download.docker.com/linux/debian buster/stable amd64 docker-ce-cli amd64 5:20.10.3~3-0~debian-buster [41.4 MB]
Fetched 41.4 MB in 12s (3,523 kB/s)
dpkg: warning: downgrading docker-ce-cli from 5:20.10.4~3-0~debian-buster to 5:20.10.3~3-0~debian-buster
(Reading database ... 91925 files and directories currently installed.)
Preparing to unpack .../docker-ce-cli_5%3a20.10.3~3-0~debian-buster_amd64.deb ...
Unpacking docker-ce-cli (5:20.10.3~3-0~debian-buster) over (5:20.10.4~3-0~debian-buster) ...
Setting up docker-ce-cli (5:20.10.3~3-0~debian-buster) ...
Processing triggers for man-db (2.8.5-2) ...
Scanning processes...
Scanning candidates...
Scanning linux images...
Running kernel seems to be up-to-date.
Failed to check for processor microcode upgrades.
Restarting services...
systemctl restart hassio-supervisor.service
No containers need to be restarted.
User sessions running outdated binaries:
david @ user manager service: systemd[22601]
david@debian:~$ sudo apt-mark hold docker-ce-cli
docker-ce-cli set on hold.
That worked for me, too. I just ran sudo apt install docker-ce-cli=5:20.10.3~3-0~debian-buster and then restarted for good measure, and itās all back to normal.
