I think, we figured out the problem.
Now we need a solution, but I am not an developer 
Just a little Sherlock 
Easiest would be the developers will build the new hassio_audio on alpine 3.12 again.
None the less, I will try to get this to work, tomorrow.
2 Likes
I‘m facing the same problem. Hope there will be a solution
I just registered to say thank you!
I was about to reinstall the system - which obviously would have been a waste of time. For me it started yesterday after I had installed the recommended updates.
I noticed the entries of pulseaudio in the syslog and I went nuts at first, because my “illegal” supervised installation on a Raspbian has no audio at all.
Now it’s clear. I hope it can be fixed.
Thanks again.
1 Like
Okay… Someone could please try this…
Download
moby/profiles/seccomp/default.json at bc6f4cc7032544553d2304a5b47ba235dbfe5b9c · moby/moby · GitHub
copy this file to your raspberry into /etc/docker/
edit the file and replace in line 2 SCMP_ACT_ERRNO with SCMP_ACT_TRACE with the command
sudo nano /etc/docker/default.json
then
sudo nano /etc/docker/daemon.json
and add the following line:
“seccomp-profile”: “/etc/docker/default.json”,
between the two existing lines
restart the raspberry and look if it works…
if not, delete the seccomp-profile line in daemon.json again…
Ahh, and save your changes in nano every time with control+o enter
control+x to quit…
19 Likes
It looks like it worked!
The
sudo docker exec -it hassio_audio ping 8.8.8.8
works correct, the
sudo docker exec -it hassio_audio date
gives the correct date.
CPU usage of hassio_audio about 1-2% instead of 20-30% earlier
Thanks for the work you’ve done!
Hi,
In my case does´nt work, but I have the HASS installed in OrangePi One, but until yesterday it worked fine. My system is:
System Health
version: core-2021.2.3
installation_type: Home Assistant Supervised
dev: false
hassio: true
docker: true
virtualenv: false
python_version: 3.8.7
os_name: Linux
os_version: 5.10.16-sunxi
arch: armv7l
timezone: Europe/Lisbon
logged_in: false
can_reach_cert_server: ok
can_reach_cloud_auth: ok
can_reach_cloud: ok
host_os: Armbian 21.02.2 Buster
update_channel: stable
supervisor_version: supervisor-2021.02.11
docker_version: 20.10.3
disk_total: 28.7 GB
disk_used: 3.5 GB
healthy: true
supported: failed to load: Unsupported
supervisor_api: ok
version_api: ok
installed_addons: Duck DNS (1.12.5), File editor (5.2.0)
dashboards: 1
resources: 0
mode: auto-gen
The last line in log:
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.
Some solution to this system?..
Thanks in advance…
AWESOME! This works perfect! 1/3 less cpu usage, nothing in the logs and the ping from ha_audio now work. Thanks a lot!!
Even im a developer, im not big into docker and have never heard about ENOSYS/EPERM. It would be great if you find the time and can explain what i just did with these changes? I have read your “the Problem” Posting, but i did not understand a lot.
Thanks again!
Good job!!!
It worked!
Raspberry Pi4b 4Gb
Linux raspberrypi 5.10.16-v7l+ #1402 SMP Tue Feb 16 14:12:18 GMT 2021 armv7l GNU/Linux
Core Version core-2021.2.3
Supervisor Version supervisor-2021.02.11
Docker version 20.10.3
thank you very much. It seems to work.
Thank you. For me the SSD write problem solved. But still use the process 10%+ from CPU.
The error “clock_gettime CLOCK_REALTIME failed” prompted me to check the system time inside the container. As I saw the strange output from the command “date” and I was pretty sure it have to has something to do with that.
As some of you confirmed me to have the same strange output, I began my research:
I think the developers uses alpine linux 3.13 on the last hassio_audio container.
I figured out, that in alpine 3.13 there was a change in a file called “musl” which uses new time64-compatible system calls that are not compatible with a library on the host system (raspbian in our case) which is called libseccomp.
musl 1.2 requires libseccomp at least 2.4.2 or greater. Raspbian still uses 2.3.3.
The fix in the docker daemon allows the container to fall back to 32-bit time system calls…
2 Likes
@Dominik.W
Absolutely great! Me and my SSD love you, man… 
Your assumption of Alpine 3.13 for the pulse_audio container is correct. But currently (22-Feb-2021) there are more images using 3.13, and the others did not fail before the LIBSECCOMP fix. Surely we don’t know exactly what happens in each of them, but the container date was correct in e.g. Supervisor.
Below is the OS version and image tag of the containers I currently run:
addon_core_configurator - Alpine Linux 3.12.1 - 5.2.0
hassio_audio - Alpine Linux 3.13.1 - 2021.02.1
hassio_cli - Alpine Linux 3.13.1 - 2021.02.1
hassio_dns - Alpine Linux 3.13.0 - 2021.01.0
hassio_multicast - Alpine Linux 3.12.0 - 3
hassio_observer - Alpine Linux 3.12.0 - 2020.10.1
hassio_supervisor - Alpine Linux 3.13.1 - 2021.02.11
homeassistant - Alpine Linux 3.12.13 - 2021.2.3
nodered - Alpine Linux 3.11.6 - latest
mosquitto - Alpine Linux 3.12.1 - latest
I got that from the /etc/os-release file of each container:
docker exec -it hassio_audio cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.13.1
PRETTY_NAME="Alpine Linux v3.13"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
1 Like
Thanks a lot! It’s fine now.
I mentioned before that my sensor data was now showing, it was because faulty database, i did not have any valuable info there so i deleted and now its super fine
Yes.
hassio_cli and hassio_dns were running without this fault.
But they also had a broken system clock.
There was simply no code used, that let them run into this error…
but sooner or later something similar would have happened there, too…
PS: The ping command uses the system time too, to check the time in ms the ping needs.
For that cause, the ping command also failed on this containers with an similar (not exact the same, but similar) error…
And the best thing is, we don’t have an hacky workaround like retagging an old container or something like that.
We just solved the problem.
good Job Dominik!
I notice some strange timestamps after your patch. Some Sensors are coming around 30sec from the future. They are showing like: Last update: in 30sec.
Is this related?
I didn’t realized something like this in my HA…
I don‘t see any correlation.
Thank you so much!
It works great, finally the spam attack in syslog is over.
I think quote marks were copied incorrectly when copying the text.
It should be like this in the daemon.json:
“seccomp-profile”: “/etc/docker/default.json”,
not
„seccomp-profile“: „/etc/docker/default.json“,`
This is quite obvious when looking at the other two entries in the file, but if someone doesn’t think about it, it will cause an error.
1 Like