Sun - 40447 20480:16:1993017536 +1994436387
If I am right, the fault traces back to the broken system time inside the container…
For me, hassio_audio:2021.02.1 is running now after restoring my backup.
It shows the correct system date and time.
Yesterday, the error came back after a restart and the system time was broken…
At the moment I have no idea why this happens.
After some research I think it is a problem with alpine 3.13 on armv7…
Could you please try to ping something?
sudo docker exec -it hassio_audio ping 8.8.8.8
If the ping should work, you can cancel with ctrl+c
But I think you will also get an clock error…
Culprit seems to be musl 1.2 in alpine 3.13
https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#musl_1.2
Yes, you are right
ping: clock_gettime(MONOTONIC) failed
1 Like
The problem:
Therefore, the following platforms are not suitable as Docker hosts for 32-bit Alpine Linux 3.13.0, due to containing out-of-date libseccomp: Amazon Linux 1 or 2, CentOS 7 or 8, Debian stable without debian-backports, Raspbian stable, Ubuntu 14.04 or earlier, and Windows. This applies regardless of whether the Linux distribution Docker packages or separate Docker package repositories are used.
Perhaps a solution:
In order to run under old Docker or libseccomp versions, the moby default seccomp profile should be downloaded and on line 2, defaultAction changed to SCMP_ACT_TRACE , then --seccomp-profile=default.json can be passed to dockerd, or --security-opt=seccomp=default.json passed to docker create or docker run . This will cause the system calls to return ENOSYS instead of EPERM, allowing the container to fall back to 32-bit time system calls. In this case, the container will not be compatible with dates past 2038.
Alternatively, --security-opt=seccomp=unconfined can be passed with no default.json required, but note that this will reduce the security of the host against malicious code in the container.
2 Likes
Ping and date from my RP3
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: clock_gettime(MONOTONIC) failed
Sun - 40447 20480:16:1993161344 +1994579747
I’m not so familiar with coding and don’t know what to do with your answer.
1 Like
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