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
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.
How often are all you guys rebooting the host to even see this as a problem? If you reboot the host all the time I would have to ask why?
Got it, my mistake. Thanks for the heads up.
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.
totaly flabberghasted right now.
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.
sudo apt remove docker-ce docker-ce-rootless-extras docker-ce-cli
sudo apt autoremove --purge -y
sudo apt install docker-ce=5:20.10.3~3-0~debian-buster docker-ce-rootless-extras=5:20.10.3~3-0~debian-buster docker-ce-cli=5:20.10.3~3-0~debian-buster
sudo apt-mark hold docker-ce docker-ce-rootless-extras docker-ce-cli
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:
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 linux images...
Running kernel seems to be up-to-date.
Failed to check for processor microcode upgrades.
systemctl restart hassio-supervisor.service
No containers need to be restarted.
User sessions running outdated binaries:
david @ user manager service: systemd
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.
I’m still on docker 20.10.3.
Does the new supervisor fix this?
I’m on the latest I can see 2021.02.11
New docker 20.10.5… installing…
All is well
Thank you for the info, David.
sudo apt-mark unhold docker-ce docker-ce-cli containerd.io
sudo apt update && apt upgrade -y && apt autoremove
updates docker to 20.10.5.
It even survives a system reboot
Yeah. As usual I didn’t reboot but all is working perfectly.
What about the docker-cli? Do we also unhold it? I read in previous posts that this was the problem after all. On which version are you on?
It’s obvious if you read the post you quoted.