[Solved] hassio_audio is in boot loop and spams my syslog with errors

Hello.

I have this problem since yesterday. Before everything was fine…

hassi_audio always stops with this error:

E: [pulseaudio] core-rtclock.c: Assertion 'clock_gettime(CLOCK_REALTIME, &ts) == 0' failed at ../src/pulsecore/core-rtclock.c:93, function pa_rtclock_get(). Aborting.

Than its rebooting all the time and spams my syslog with tons of errors!
If I stop the container, the supervisor restarts it.
How can I fix this?

Same Problem here since some days.
This is really frustrating.

eb 20 00:42:56 homeassistant 254c16c1fd06[1098]: I: [pulseaudio] module.c: Loaded "module-card-restore" (index: #2; argument: "").                                                                                                                                           │
│Feb 20 00:42:56 homeassistant 254c16c1fd06[1098]: I: [pulseaudio] module.c: Loaded "module-switch-on-port-available" (index: #3; argument: "").                                                                                                                               │
│Feb 20 00:42:56 homeassistant 254c16c1fd06[1098]: I: [pulseaudio] module.c: Loaded "module-switch-on-connect" (index: #4; argument: "").                                                                                                                                      │
│Feb 20 00:42:56 homeassistant 254c16c1fd06[1098]: D: [pulseaudio] module-udev-detect.c: /dev/snd/controlC0 is accessible: yes                                                                                                                                                 │
│Feb 20 00:42:56 homeassistant 254c16c1fd06[1098]: W: [pulseaudio] module-udev-detect.c: Failed to open /proc/asound/card0: No such file or directory                                                                                                                          │
│Feb 20 00:42:56 homeassistant 254c16c1fd06[1098]: D: [pulseaudio] module-udev-detect.c: /devices/platform/soc/fe00b840.mailbox/bcm2835_audio/sound/card0 is busy: no                                                                                                          │
│Feb 20 00:42:56 homeassistant 254c16c1fd06[1098]: E: [pulseaudio] core-rtclock.c: Assertion 'clock_gettime(CLOCK_REALTIME, &ts) == 0' failed at ../src/pulsecore/core-rtclock.c:93, function pa_rtclock_get(). Aborting.                                                      │
   

I dont even need Audio at all. But i cant find an option the deactivate the audio stuff.

Yes. Exactly the same messages…
I really need a workaround.
It creates 1 GB of syslog per day!

Okay. Here is what I figured out so far.
The error comes from a wrong date inside the container!
How can we fix this?

Bildschirmfoto 2021-02-20 um 09.48.28

Okay. I thought that the filesystem was corrupt, because my raspberry hung up and I had to unplug the power cord.

I had a full dump of the sdcard which was two weeks old. I decided to restore this and make all the changes of the last 2 weeks again…

Everything worked fine, until I did an apt update && apt upgrade.
After that the error came back.

I don’t know which packages causes the error. I am running hassio supervised on unsupported raspbian with OMV5.

Can anyone of you think what caused the error, so I could downgrade that package?

Here is the upgrade log:

2021-02-20 14:33:36 upgrade base-files:armhf 10.3+rpi1+deb10u7 10.3+rpi1+deb10u8
2021-02-20 14:33:37 upgrade systemd-sysv:armhf 241-7~deb10u5+rpi1 241-7~deb10u6+rpi1
2021-02-20 14:33:37 upgrade libpam-systemd:armhf 241-7~deb10u5+rpi1 241-7~deb10u6+rpi1
2021-02-20 14:33:38 upgrade libsystemd0:armhf 241-7~deb10u5+rpi1 241-7~deb10u6+rpi1
2021-02-20 14:33:39 upgrade libnss-myhostname:armhf 241-7~deb10u5+rpi1 241-7~deb10u6+rpi1
2021-02-20 14:33:39 upgrade systemd:armhf 241-7~deb10u5+rpi1 241-7~deb10u6+rpi1
2021-02-20 14:33:42 upgrade udev:armhf 241-7~deb10u5+rpi1 241-7~deb10u6+rpi1
2021-02-20 14:33:43 upgrade libudev1:armhf 241-7~deb10u5+rpi1 241-7~deb10u6+rpi1
2021-02-20 14:33:44 upgrade libgnutls30:armhf 3.6.7-4+deb10u5 3.6.7-4+deb10u6
2021-02-20 14:33:45 upgrade rpi-chromium-mods:armhf 20210118 20210212
2021-02-20 14:33:46 upgrade libzstd1:armhf 1.3.8+dfsg-3+rpi1 1.3.8+dfsg-3+rpi1+deb10u1
2021-02-20 14:33:47 upgrade iproute2:armhf 4.20.0-2 4.20.0-2+deb10u1
2021-02-20 14:33:47 upgrade bind9-host:armhf 1:9.11.5.P4+dfsg-5.1+deb10u2 1:9.11.5.P4+dfsg-5.1+deb10u3
2021-02-20 14:33:48 upgrade libbind9-161:armhf 1:9.11.5.P4+dfsg-5.1+deb10u2 1:9.11.5.P4+dfsg-5.1+deb10u3
2021-02-20 14:33:48 upgrade libisccfg163:armhf 1:9.11.5.P4+dfsg-5.1+deb10u2 1:9.11.5.P4+dfsg-5.1+deb10u3
2021-02-20 14:33:48 upgrade libisccc161:armhf 1:9.11.5.P4+dfsg-5.1+deb10u2 1:9.11.5.P4+dfsg-5.1+deb10u3
2021-02-20 14:33:49 upgrade libssl-dev:armhf 1.1.1d-0+deb10u4+rpt1 1.1.1d-0+deb10u5+rpt1
2021-02-20 14:33:49 upgrade libssl1.1:armhf 1.1.1d-0+deb10u4+rpt1 1.1.1d-0+deb10u5+rpt1
2021-02-20 14:33:50 upgrade libdns1104:armhf 1:9.11.5.P4+dfsg-5.1+deb10u2 1:9.11.5.P4+dfsg-5.1+deb10u3
2021-02-20 14:33:50 upgrade libisc1100:armhf 1:9.11.5.P4+dfsg-5.1+deb10u2 1:9.11.5.P4+dfsg-5.1+deb10u3
2021-02-20 14:33:51 upgrade liblwres161:armhf 1:9.11.5.P4+dfsg-5.1+deb10u2 1:9.11.5.P4+dfsg-5.1+deb10u3
2021-02-20 14:33:51 upgrade file:armhf 1:5.35-4+deb10u1 1:5.35-4+deb10u2
2021-02-20 14:33:51 upgrade libmagic1:armhf 1:5.35-4+deb10u1 1:5.35-4+deb10u2
2021-02-20 14:33:52 upgrade libmagic-mgc:armhf 1:5.35-4+deb10u1 1:5.35-4+deb10u2
2021-02-20 14:33:52 upgrade btrfs-progs:armhf 4.20.1-2 5.10-1~bpo10+1
2021-02-20 14:33:53 upgrade cockpit-bridge:armhf 235-1~bpo10+1 237-1~bpo10+1
2021-02-20 14:33:53 upgrade openssl:armhf 1.1.1d-0+deb10u4+rpt1 1.1.1d-0+deb10u5+rpt1
2021-02-20 14:33:53 upgrade cockpit-ws:armhf 235-1~bpo10+1 237-1~bpo10+1
2021-02-20 14:33:55 upgrade cockpit-system:all 235-1~bpo10+1 237-1~bpo10+1
2021-02-20 14:33:56 upgrade cockpit:all 235-1~bpo10+1 237-1~bpo10+1
2021-02-20 14:33:56 upgrade cockpit-packagekit:all 235-1~bpo10+1 237-1~bpo10+1
2021-02-20 14:33:57 upgrade device-tree-compiler:armhf 1.4.7-3+rpt1 1.4.7-4
2021-02-20 14:33:57 upgrade libblockdev-utils2:armhf 2.20-7+deb10u1 2.20-7+deb10u1+b1
2021-02-20 14:33:57 upgrade libblockdev-part-err2:armhf 2.20-7+deb10u1 2.20-7+deb10u1+b1
2021-02-20 14:33:57 upgrade libblockdev-fs2:armhf 2.20-7+deb10u1 2.20-7+deb10u1+b1
2021-02-20 14:33:58 upgrade libblockdev-loop2:armhf 2.20-7+deb10u1 2.20-7+deb10u1+b1
2021-02-20 14:33:58 upgrade libblockdev-part2:armhf 2.20-7+deb10u1 2.20-7+deb10u1+b1
2021-02-20 14:33:58 upgrade libblockdev-swap2:armhf 2.20-7+deb10u1 2.20-7+deb10u1+b1
2021-02-20 14:33:58 upgrade libblockdev2:armhf 2.20-7+deb10u1 2.20-7+deb10u1+b1
2021-02-20 14:33:59 upgrade libisc-export1100:armhf 1:9.11.5.P4+dfsg-5.1+deb10u2 1:9.11.5.P4+dfsg-5.1+deb10u3
2021-02-20 14:33:59 upgrade libdns-export1104:armhf 1:9.11.5.P4+dfsg-5.1+deb10u2 1:9.11.5.P4+dfsg-5.1+deb10u3
2021-02-20 14:34:00 upgrade libwebkit2gtk-4.0-37:armhf 2.30.4-1~deb10u1+rpi1 2.30.5-1~deb10u1+rpi1
2021-02-20 14:34:04 upgrade libjavascriptcoregtk-4.0-18:armhf 2.30.4-1~deb10u1+rpi1 2.30.5-1~deb10u1+rpi1
2021-02-20 14:34:05 upgrade libpq5:armhf 11.9-0+deb10u1 11.10-0+deb10u1
2021-02-20 14:34:05 upgrade libsnmp-base:all 5.7.3+dfsg-5+deb10u1 5.7.3+dfsg-5+deb10u2
2021-02-20 14:34:06 upgrade libsnmp30:armhf 5.7.3+dfsg-5+deb10u1 5.7.3+dfsg-5+deb10u2
2021-02-20 14:34:06 upgrade node-ini:all 1.3.5-1 1.3.5-1+deb10u1
2021-02-20 14:34:07 upgrade node-y18n:all 3.2.1-2 3.2.1-2+deb10u1
2021-02-20 14:34:07 upgrade nodered:armhf 1.0.6-1 1.2.9-1
2021-02-20 14:34:33 upgrade openmediavault-omvextrasorg:all 5.4.5 5.5.1
2021-02-20 14:34:33 upgrade php7.3-bcmath:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:34 upgrade php7.3-zip:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:35 upgrade php7.3-xml:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:37 upgrade php7.3-readline:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:38 upgrade php7.3-opcache:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:38 upgrade php7.3-mbstring:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:39 upgrade php7.3-json:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:40 upgrade php7.3-gd:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:40 upgrade php7.3-curl:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:41 upgrade php7.3-cgi:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:41 upgrade php7.3-fpm:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:42 upgrade php7.3-cli:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:43 upgrade php7.3-common:armhf 7.3.19-1~deb10u1 7.3.27-1~deb10u1
2021-02-20 14:34:48 upgrade openmediavault:all 5.5.23-1 5.6.0-1
2021-02-20 14:34:58 upgrade pcmanfm:armhf 1.3.1-1+rpt25 1.3.1-1+rpt26
2021-02-20 14:34:58 upgrade raspberrypi-sys-mods:armhf 20210125 20210208
2021-02-20 14:35:04 upgrade raspi-config:all 20210119 20210212
2021-02-20 14:35:05 upgrade rp-prefapps:armhf 0.30 0.32
2021-02-20 14:35:05 upgrade rpi-eeprom:armhf 11.6-1 11.7-1
2021-02-20 14:35:07 upgrade unzip:armhf 6.0-23+deb10u1 6.0-23+deb10u2

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.

Yes. I tried everything. No chance…

I think we have to wait until the developers update the hassio_audio container :slightly_frowning_face:

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.

docker pause hassio_supervisor
docker pause hassio_audio

Of course some pages in HA Lovelace won’t work, but at least your sensors and automations etc. may be ok.

Yes. I did that, too. Thank you.

@JoFie, @corgan

Are you running home assistant on an raspberry?

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.

The add-on doesn’t work here

Yep, running HA on a RPi 4.

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?

Perhaps they didn’t restart their host, yet.

It’s also interesting if this happens on armhf / armv7 only.

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…

Today:
grafik

oh and I forgot to mention, that the system load increased by 50% and the cpu temp by around 10°C… Since i did the last update…

I think this error is keeping my sensor graphs flat lined too. Correct data is shown with number but graph stays still.
image

@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.