Okay. It has nothing to do with this system updates…
After another restore it works until I restart the raspberry.
Then the error comes back…
The supervisor watchdog always pulls armv7-hassio-audio:2021.02.01
The fault must be in this container…
@Dominik.W
I now have the same problem, and roughly the same history as you. Running HA in Supervised mode in Docker. I restored my setup yesterday after a corrupt SSD. It ran fine for a short period, until I updated to a new HA version, and did some other changes to try and reduce the wear on my new SSD.
I also traced it back to hassio_audio . My version is “2021.2.1”.
It seems to fail here, and then restart in a tight loop.
core-rtclock.c: Assertion 'clock_gettime(CLOCK_REALTIME, &ts) == 0' failed at ../src/pulsecore/core-rtclock.c.93, function pa_rtclock_get(). Aborting.
One option just to keep HA running in the meantime, is to suspend (or stop?) the hassio_audio container, but you also have to suspend hassio_supervisor to prevent it from starting hassio_audio in the background again.
There is a whole discussion in Github going about disabling audio in HA, but the developers won’t bite.
I suspect there is a fair amount of HA users who don’t care about the audio, and it just consumes resources and wears out your SD/SSD by writing trace data to the log.
There seems to be a HA addon that will stop PulseAudio, albeit for a different reason. But you may want to try this as a (temporary?) workaround until the root cause is fixed.
Is this logged somewhere as a showstopper error? @corgan apparently experiences the problem for “some days” already, and it is not fixed yet.
What do we have that is different? If all HA users experience this problem there would have been a major outcry. Or… they don’t know they have it?
I have RP3 (Rasbian OS and trying to use HA Supervisor) and same problem. Im trying to restore my snapshot but this error seems to be causing problems, if i paused HA audio it started to move something.
What I have seen, this problem only appears on unsupported installations, like mine (Raspbian 10 Buster) and if you reboot your system after an apt-update.
The HA-Audio Add-on caused the problem, but the developer are really like these old school linux gurus in the forums in the old days. It’s not official supported, so we don’t care. Re-install and let take HA in control the system. That everything runs totally fine (except ha-audio), doesn’t matter.
That basically what they told the several other users.
OK, you can act like this, but that’s for me the first time i that i must read something like that in this community.
For me, the biggest question is, why the developer don’t give us the choice to deactivate this crap ha-audio add-on. I don’t need anything from it. There are so many people here in the Forum and on GitHub begging for it, but we don’t even get an answer, why we can’t deactivate it. And this arrogant behavior really shocked me.
I have a huge setup with hundreds of sensors from outside ha. Reinstallation is no option, because i don’t have the time that this would take. Everything would be fine, if we only could deactivate a (for me) useless add-on.
If you have time, here are some best-of ha-audio problems.
Forget to mention, I still don’t have a solution. The OPHoperHPO/hassio-addons only works on the last version and is not updated to work on the new ha.audio.
I searched hours for a “not that hacky” docker rm ha-audio container solution, but there is nothing i can do atm, as to look at my logfiles size going crazy…
@ToreTigu I had this when my previous SSD failed. HA was still running, buttons and automations still functioned as if nothing was wrong. But when I rebooted the RPi at some point it just hanged and nothing happened. Turned out the SSD was in read-only mode as a way to prevent data loss, but I could not write to the disk anymore. This allowed me to make images of the boot and root partitions and restore that later to my new disk.
If you did not reboot/restart yet since you saw this, make sure you have a backup that you can restore later. If you can still create a HA snapshot, then you’re good and a disk failure seems not the cause. If you can’t, and you don’t have a recent snapshot, then at the very least you can edit your files and copy/paste the contents to files in Windows or wherever. Depending on what you’ve done with HA, I would consider e.g. configuration.yaml, secrets, scripts, automations, … , and go into Lovelace raw edit and copy the full definitions of your pages.