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

Hi Kevin
Just for the record, I’m relatively new to this whole thing, so at this point I’m just shooting from the hip trying to help.

Regarding the multiple supervisor images, I also noticed that I had it last week, and I got rid of it executing the Docker command below. Note that according to the Docker documentation this will remove all images that are not linked to running containers (!), so be careful that you don’t loose something important.

# Delete Docker Images not linked to a running Container.
docker image prune

The actual Home Assistant container is homeassistant, so what is the home_assistant container? It is not running, so in theory it should not be a problem, but just to eliminate possible causes, and if you don’t use it anymore, can you remove the container? Try

docker rm home_assistant

About the connection refused problem…

What I miss in your hassio_audio process list is the PulseAudio service, shown below.

pulseaudio --system -vvv --disallow-exit --exit-idle-time=-1 --disable-shm

For your reference, below is the processes that are running in hassio_audio in my environment:

docker exec -it hassio_audio ps -ef
PID   USER     TIME  COMMAND
    1 root      0:00 s6-svscan -t0 /var/run/s6/services
   35 root      0:00 s6-supervise s6-fdholderd
  571 root      0:00 s6-supervise alsa
  572 root      0:00 s6-supervise pulseaudio
  575 root      0:00 bash /usr/bin/bashio ./run
  576 root      1:52 pulseaudio --system -vvv --disallow-exit --exit-idle-time=-1 --disable-shm
  601 root      0:00 bash /usr/bin/bashio ./run
  602 root      0:00 udevadm monitor --subsystem-match=sound
  610 root      0:00 bash
  619 root      0:00 ps -ef

Can you see any errors in the hassio_audio container logs why the PulseAudio process fails to start? Are you sure you are not experiencing the problem that started this thread, and if yes did you implement the solution provided by Dominik, as explained here?

docker logs -f hassio_audio

Are you running this on a RPi, or something else? Are you actually using audio on this device, either in Home Assistant or on the device itself? Can you make sure that nothing is using audio when you are executing the commands?

Ok, you can execute commands in the container, so it looks like PulseAudio and the “pactl” commands are causing the error.
Can you try to run a Bash shell in the container, and then from this session try to list the loaded modules and try to load the “suspend” module? I see you are running Portainer… you can also open a console session in the Container from the Portainer UI.

# Connect and run a Bash shell in the hassio_audio container, or use Portainer.
docker exec -it hassio_audio bash

# If successful, you should now be root in a Bash shell in the hassio_audio container.
# Confirm who you are, then try to execute the "pactl" commands again.
whoami
ps -ef | grep pulse

# If the PulseAudio process is running (look for "pulseaudio --system -vvv ...." )
# then try to run the "pactl" command as root directly from inside the container
pactl list modules
pactl load-module module-suspend-on-idle

# kill the PulseAudio process. It should be automatically restarted immediately again. Then try "pactl" again.
kill <PID>

Hi JoFie, thanks for your time!

I’m running everything on a RPi4b and I don’t use audio at all. I implemented Dominik solution without luck.

home_assistant was coming from a docker-compose (I’m using IOTStack). I removed it but still have the same problem.

pulseaudio --system -vvv --disallow-exit --exit-idle-time=-1 --disable-shm

I: [pulseaudio] main.c: Using runtime directory /run/user/1000/pulse.
I: [pulseaudio] main.c: Using state directory /home/pi/.config/pulse.
I: [pulseaudio] main.c: Using modules directory /usr/lib/pulse-12.2/modules.
I: [pulseaudio] main.c: Running in system mode: no
E: [pulseaudio] pid.c: Daemon already running.
E: [pulseaudio] main.c: pa_pid_file_create() failed.

docker exec -it hassio_audio ps -ef

    1 root      0:00 s6-svscan -t0 /var/run/s6/services
   35 root      0:00 s6-supervise s6-fdholderd
  570 root      0:00 s6-supervise alsa
  571 root      0:03 s6-supervise pulseaudio
  575 root      0:00 bash /usr/bin/bashio ./run
  600 root      0:00 bash /usr/bin/bashio ./run
  601 root      0:00 udevadm monitor --subsystem-match=sound
10793 root      0:00 ps -ef

whoami returns root

ps -ef | grep pulse

  573 root      0:00 s6-supervise pulseaudio
  576 root      0:59 pulseaudio --system -vvv --disallow-exit --exit-idle-time=-1 --disable-shm
  612 root      0:00 grep pulse

I’ll reinstall everything…starting with hass.io first, make sure I don’t have those errors and then IOTstack.

Thank you for your help!

Kevin
I also used IOTstack to set up my environment.
Maybe the difference is in how you added Home Assistant? I did not add Home Assistant from the IOTStack menu, so it is not in my IOTstack docker-compose.yaml. I added it afterwards (maybe following similar steps as the HA install part in this guide, I can’t remember). IOTstack also changed since I did it, back then it was still managed by a South African guy named Graham Garner.

You can also try to search for or post your question in the IOTstack discord forum.

To me the problem is that PulseAudio is not running in your hassio_audio, and you must figure out why that is. Is it indeed in a “boot loop”, as this thread title describes? If you say Dominik’s solution did not help, is it still in a boot loop/continuously trying to restart?

What is the date in your hassio_audio, is it the correct date?

docker exec -it hassio_audio date

When I kill the PulseAudio process in my container, it is automatically and almost immediately restarted. It uses the runtime parameters specified in “/run/s6/services/pulseaudio/run”, you can change it before killing the PulseAudio process so it uses your new parameters when it restarts.
e.g. to show a timestamp in the logs add " --log-time=yes"
The default parameters are defined in “/etc/pulse/daemon.conf

But a different question… if the hassio_audio container does not flood your logs with errors, and it has no CPU usage, and you also don’t use audio in Home Assistant, then what is the concern if it does not work?

Hi Johan,

I followed your mail and the remaining post thread.

root@raspberrypi:~# docker ps

CONTAINER ID   IMAGE                                                COMMAND                  CREATED             STATUS             PORTS                              NAMES
33130d93ccdf   ghcr.io/hassio-addons/portainer/armv7:1.4.0          "/init"                  19 minutes ago      Up 19 minutes                                         addon_a0d7b954_portainer
22a560d676aa   homeassistant/armv7-addon-samba:9.3.1                "/init"                  34 minutes ago      Up 34 minutes                                         addon_core_samba
01f97f3670fb   homeassistant/raspberrypi4-homeassistant:2021.3.0    "/init"                  36 minutes ago      Up 36 minutes                                         homeassistant
f32030b0d993   homeassistant/armv7-hassio-audio:2021.02.1           "/init"                  44 minutes ago      Up 44 minutes                                         hassio_audio
fa08c037199e   sabeechen/hassio-google-drive-backup-armv7:0.103.1   "python3 -m backup"      59 minutes ago      Up 59 minutes      0.0.0.0:1627->1627/tcp, 8099/tcp   addon_cebe7a76_hassio_google_drive_backup
a38d48095020   ghcr.io/hassio-addons/sqlite-web/armv7:3.0.1         "/init"                  59 minutes ago      Up 59 minutes                                         addon_a0d7b954_sqlite-web
aef28c648b47   ghcr.io/hassio-addons/appdaemon/armv7:0.4.3          "/init"                  About an hour ago   Up 59 minutes      0.0.0.0:5050->5050/tcp             addon_a0d7b954_appdaemon
072b5f782f56   homeassistant/armv7-addon-configurator:5.2.0         "/init"                  About an hour ago   Up About an hour                                      addon_core_configurator
9f7fd82d03f2   ghcr.io/hassio-addons/grafana/armv7:6.1.2            "/init"                  About an hour ago   Up About an hour                                      addon_a0d7b954_grafana
2beabe851025   ghcr.io/hassio-addons/glances/armv7:0.11.1           "/init"                  About an hour ago   Up About an hour                                      addon_a0d7b954_glances
e7ca67476eac   ghcr.io/hassio-addons/ssh/armv7:8.0.3                "/init"                  About an hour ago   Up About an hour                                      addon_a0d7b954_ssh
ecd756be02a0   homeassistant/armv7-addon-duckdns:1.12.5             "/init /run.sh"          About an hour ago   Up About an hour                                      addon_core_duckdns
90436c333322   homeassistant/armv7-hassio-supervisor                "/init"                  About an hour ago   Up About an hour                                      hassio_supervisor
e67a9f490562   homeassistant/armv7-hassio-multicast:3               "/init"                  About an hour ago   Up About an hour                                      hassio_multicast
c91a25202bdf   homeassistant/armv7-hassio-cli:2021.02.1             "/init /bin/bash -c …"   About an hour ago   Up About an hour                                      hassio_cli
cdf55f418407   homeassistant/armv7-hassio-dns:2021.01.0             "/init"                  About an hour ago   Up About an hour                                      hassio_dns
330a6836e421   homeassistant/armv7-hassio-observer:2020.10.1        "/init"                  5 days ago          Up 5 days          0.0.0.0:4357->80/tcp               hassio_observer
root@raspberrypi:~# docker images

REPOSITORY                                   TAG         IMAGE ID       CREATED        SIZE
homeassistant/armv7-hassio-supervisor        2021.03.4   63b35e3f34e5   3 hours ago    249MB
homeassistant/armv7-hassio-supervisor        latest      63b35e3f34e5   3 hours ago    249MB
homeassistant/raspberrypi4-homeassistant     2021.3.0    60c5765a6214   23 hours ago   1.03GB
homeassistant/armv7-addon-samba              9.3.1       946d4c8915db   7 days ago     98MB
ghcr.io/hassio-addons/glances/armv7          0.11.1      0b54d7aca8e1   13 days ago    99.1MB
ghcr.io/hassio-addons/ssh/armv7              8.0.3       57b59683e2cb   13 days ago    308MB
ghcr.io/hassio-addons/sqlite-web/armv7       3.0.1       1b49772aa200   13 days ago    88.6MB
ghcr.io/hassio-addons/grafana/armv7          6.1.2       596f61a548b5   2 weeks ago    307MB
homeassistant/armv7-hassio-audio             2021.02.1   40f28e0fd362   2 weeks ago    90.5MB
homeassistant/armv7-hassio-cli               2021.02.1   468da71074dd   2 weeks ago    81MB
homeassistant/armv7-addon-duckdns            1.12.5      9e8282c0ea0a   3 weeks ago    71.9MB
ghcr.io/hassio-addons/appdaemon/armv7        0.4.3       a03186a55903   3 weeks ago    273MB
homeassistant/armv7-hassio-dns               2021.01.0   eeb0a3e43eb4   5 weeks ago    85.9MB
sabeechen/hassio-google-drive-backup-armv7   0.103.1     7c53d6fdd247   5 weeks ago    181MB
ghcr.io/hassio-addons/portainer/armv7        1.4.0       948f9ce086a5   5 weeks ago    81.9MB
homeassistant/armv7-addon-configurator       5.2.0       e197f4a5c640   3 months ago   130MB
homeassistant/armv7-hassio-observer          2020.10.1   bf193dc8f2c4   4 months ago   71.8MB
homeassistant/armv7-hassio-multicast         3           0fbd536e8547   6 months ago   63.3MB

I see 2 identical image IDs for supervisor. Is that normal?

root@raspberrypi:~# docker exec -it hassio_audio ps -ef
PID   USER     TIME  COMMAND
    1 root      0:00 s6-svscan -t0 /var/run/s6/services
   35 root      0:00 s6-supervise s6-fdholderd
  426 root      0:07 s6-supervise pulseaudio
  427 root      0:00 s6-supervise alsa
  430 root      0:00 bash /usr/bin/bashio ./run
  456 root      0:00 bash /usr/bin/bashio ./run
  457 root      0:00 udevadm monitor --subsystem-match=sound
19750 root      0:00 ps -ef
root@raspberrypi:~# docker exec -it hassio_audio pactl list modules
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
root@raspberrypi:~# docker logs -f hassio_audio
. . . . . 
W: [pulseaudio] main.c: Running in system mode, but --disallow-module-loading not set.
D: [pulseaudio] core-rtclock.c: Timer slack is set to 50 us.
D: [pulseaudio] core-util.c: setpriority() worked.
I: [pulseaudio] core-util.c: Successfully gained nice level -11.
I: [pulseaudio] main.c: Found user 'root' (UID 0) and group 'root' (GID 0).
W: [pulseaudio] main.c: Home directory of user 'root' is not '/var/run/pulse', ignoring.
W: [pulseaudio] caps.c: Normally all extra capabilities would be dropped now, but that's impossible because PulseAudio was built without capabilities support.
I: [pulseaudio] main.c: Successfully changed user to "root".
I: [pulseaudio] main.c: This is PulseAudio 14.2
D: [pulseaudio] main.c: Compilation CFLAGS: Not yet supported on meson
D: [pulseaudio] main.c: Running on host: Linux armv7l 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021
D: [pulseaudio] main.c: Found 4 CPUs.
I: [pulseaudio] main.c: Page size is 4096 bytes
D: [pulseaudio] main.c: Compiled with Valgrind support: no
D: [pulseaudio] main.c: Running in valgrind mode: no
D: [pulseaudio] main.c: Running in VM: no
D: [pulseaudio] main.c: Running from build tree: no
D: [pulseaudio] main.c: Optimized build: yes
D: [pulseaudio] main.c: All asserts enabled.
I: [pulseaudio] main.c: Machine ID is 5516195366bf4721b7b110e7d4d13f00.
I: [pulseaudio] main.c: Using runtime directory /var/run/pulse.
I: [pulseaudio] main.c: Using state directory /data/states.
I: [pulseaudio] main.c: Using modules directory /usr/lib/pulse-14.2/modules.
I: [pulseaudio] main.c: Running in system mode: yes
W: [pulseaudio] main.c: OK, so you are running PA in system mode. Please make sure that you actually do want to do that.
W: [pulseaudio] main.c: Please read http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/ for an explanation why system mode is usually a bad idea.
W: [pulseaudio] pid.c: Stale PID file, overwriting.
I: [pulseaudio] main.c: System supports high resolution timers
D: [pulseaudio] memblock.c: Using private memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65496
I: [pulseaudio] cpu-arm.c: CPU flags: V6 V7 VFP EDSP NEON VFPV3
I: [pulseaudio] svolume_arm.c: Initialising ARM optimized volume functions.
I: [pulseaudio] sconv_neon.c: Initialising ARM NEON optimized conversions.
I: [pulseaudio] mix_neon.c: Initialising ARM NEON optimized mixing functions.
I: [pulseaudio] remap_neon.c: Initialising ARM NEON optimized remappers.
D: [pulseaudio] database-tdb.c: Opened TDB database '/data/states/5516195366bf4721b7b110e7d4d13f00-device-volumes.tdb'
I: [pulseaudio] database.c: Successfully opened 'device-volumes' database file '/data/states/5516195366bf4721b7b110e7d4d13f00-device-volumes.tdb'.
I: [pulseaudio] module.c: Loaded "module-device-restore" (index: #0; argument: "").
D: [pulseaudio] database-tdb.c: Opened TDB database '/data/states/5516195366bf4721b7b110e7d4d13f00-stream-volumes.tdb'
I: [pulseaudio] database.c: Successfully opened 'stream-volumes' database file '/data/states/5516195366bf4721b7b110e7d4d13f00-stream-volumes.tdb'.
D: [pulseaudio] protocol-dbus.c: Interface org.PulseAudio.Ext.StreamRestore1 added for object /org/pulseaudio/stream_restore1
I: [pulseaudio] module.c: Loaded "module-stream-restore" (index: #1; argument: "").
D: [pulseaudio] database-tdb.c: Opened TDB database '/data/states/5516195366bf4721b7b110e7d4d13f00-card-database.tdb'
I: [pulseaudio] database.c: Successfully opened 'card-database' database file '/data/states/5516195366bf4721b7b110e7d4d13f00-card-database.tdb'.
I: [pulseaudio] module.c: Loaded "module-card-restore" (index: #2; argument: "").
I: [pulseaudio] module.c: Loaded "module-switch-on-port-available" (index: #3; argument: "").
I: [pulseaudio] module.c: Loaded "module-switch-on-connect" (index: #4; argument: "").
D: [pulseaudio] module-udev-detect.c: /dev/snd/controlC0 is accessible: yes
W: [pulseaudio] module-udev-detect.c: Failed to open /proc/asound/card0: No such file or directory
D: [pulseaudio] module-udev-detect.c: /devices/platform/soc/fe00b840.mailbox/bcm2835_audio/sound/card0 is busy: no
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.

There is an error: Failed to open /proc/asound/card0: No such file or directory

I also see that this container is reloaded every 10-15 seconds because this process is failed due to errors seen above.

root@raspberrypi:~# docker exec -it hassio_audio bash
bash-5.1# whoami
root
bash-5.1# ps -ef | grep pulse
  426 root      0:05 s6-supervise pulseaudio
15515 root      0:00 grep pulse
bash-5.1# pactl list modules
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
bash-5.1# pactl load-module module-suspend-on-idle
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

root@raspberrypi:~# docker exec -it hassio_supervisor date
Thu Mar  4 18:46:57 UTC 2021
root@raspberrypi:~# docker exec -it hassio_audio date
Sun - 40447 20480:16:-1227370880  -1225953501

The latter is corrupted. It does not show the date correctly.

What is next step? Do you think a re-installation of complete system including Rpi4 - RaspiOS lite (buster) 32-bit installation will help to solve this issue?

It is now solved. I followed the solution in this thread like

Download default.json...suggested by Dominik Weiland

docker logs -f hassio_audio gives

D: [pulseaudio] bluez5-util.c: oFono is running: no
D: [pulseaudio] backend-native.c: Registering Profile /Profile/HSPHSProfile 00001108-0000-1000-8000-00805f9b34fb
D: [pulseaudio] bluez5-util.c: Properties changed in adapter /org/bluez/hci0
D: [pulseaudio] bluez5-util.c: Properties changed in adapter /org/bluez/hci0
D: [pulseaudio] bluez5-util.c: Properties changed in adapter /org/bluez/hci0
D: [pulseaudio] bluez5-util.c: Properties changed in adapter /org/bluez/hci0
D: [pulseaudio] bluez5-util.c: Properties changed in adapter /org/bluez/hci0
I: [pulseaudio] client.c: Created 0 "Native client (UNIX socket client)"
I: [pulseaudio] protocol-native.c: Client authenticated anonymously.
D: [pulseaudio] protocol-native.c: Protocol version: remote 34, local 34
D: [pulseaudio] protocol-native.c: SHM possible: no
D: [pulseaudio] protocol-native.c: Negotiated SHM: no
D: [pulseaudio] protocol-native.c: Disabling srbchannel, reason: No SHM support
I: [pulseaudio] client.c: Freed 0 "supervisor"
I: [pulseaudio] protocol-native.c: Connection died.

That is totally different with my part in this thread.

Erik

The problem is clear, we must just fix it. And with any luck the solution provided earlier by Dominik should do the trick.

The problem is the " clock_gettime()" error:

# from the hassio_audio logs:
...
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.
...

# the date is not set in hassio_audio (as result of above error):
docker exec -it hassio_audio date
Sun - 40447 20480:16:-1227370880  -1225953501

.



Below is the same solution provided by Dominik, I just wrote the steps in more detail.

  1. Download the “seccompdefault.json file from Github:
    https://github.com/moby/moby/blob/bc6f4cc7032544553d2304a5b47ba235dbfe5b9c/profiles/seccomp/default.json

  2. Copy the file to the Home Assistant host (Raspberry Pi), and put it in /etc/docker/

  3. Edit this newly created file, /etc/docker/default.json.
    In the second line replace
    "SCMP_ACT_ERRNO"
    with
    "SCMP_ACT_TRACE"

  4. Then also edit this file, /etc/docker/daemon.json.
    Add the text below between the two existing lines.
    (copy the line exactly as shown here, including the comma at the end)

    "seccomp-profile": "/etc/docker/default.json",

  5. Reboot, and then check if PulseAudio starts correctly in hassio_audio.
    Easiest place to start is to confirm the date in hassio_audio is correct.
    Also check the hassio_audio logs:
    docker logs hassio_audio
    and see if the PulseAudio suspend module can be loaded successfully:

    docker exec -it hassio_audio pactl load-module module-suspend-on-idle

Voilà!



Once hassio_audio starts ok, also confirm that you are not suffering from another problem, namely hassio_audio consuming excessive CPU (for an idle container), up to 16% on my RPi 4. If that is the case, then consider to implement this shell script to suspend PulseAudio in hassio_audio whenever the container is (re)started.



Below is what these files look like in my setup, as reference:

# Contents of the  /etc/docker/  directory:
ls -l /etc/docker/
total 32
-rw-r--r-- 1 root root   118 Feb 22 11:51 daemon.json
-rw-r--r-- 1 root root    97 Feb 19 16:29 daemon.json.json-driver
-rwxr--r-- 1 root root 13735 Feb 22 12:09 default.json
-rw------- 1 root root   244 Oct 24 17:58 key.json

# First 10 records of default.json (note "TRACE"):
head /etc/docker/default.json
{
        "defaultAction": "SCMP_ACT_TRACE",
        "archMap": [
                {
                        "architecture": "SCMP_ARCH_X86_64",
                        "subArchitectures": [
                                "SCMP_ARCH_X86",
                                "SCMP_ARCH_X32"
                        ]
                },

# Content of /etc/docker/daemon.json (note the line starting with "seccomp"):
cat /etc/docker/daemon.json
{
    "log-driver": "journald",
    "seccomp-profile": "/etc/docker/default.json",
    "storage-driver": "overlay2"
}

.
Below is the output when the PulseAudio module is loaded in hassio_audio.

# Manually load the PulseAudio module in hassio_audio:
docker exec -it hassio_audio pactl load-module module-suspend-on-idle
16

# /var/log/user.log entries when shell script automatically loaded the module after hassio_audio started.
Mar  8 22:43:39 JoFieHome root: pa-suspend.sh started
Mar  8 22:44:20 JoFieHome root: pa-suspend.sh (Container Start): PulseAudio - module-suspend-on-idle loaded ok (16)


# hassio_audio logs when module is loaded:
docker logs -f hassio_audio 
...
I: [pulseaudio] module.c: Loaded "module-suspend-on-idle" (index: #16; argument: "").
I: [pulseaudio] client.c: Freed 0 "pactl"
I: [pulseaudio] protocol-native.c: Connection died.
I: [pulseaudio] module-suspend-on-idle.c: Sink auto_null idle for too long, suspending ...
D: [pulseaudio] sink.c: auto_null: suspend_cause: (none) -> IDLE
D: [pulseaudio] sink.c: auto_null: state: IDLE -> SUSPENDED
D: [pulseaudio] source.c: auto_null.monitor: suspend_cause: (none) -> IDLE
D: [pulseaudio] source.c: auto_null.monitor: state: IDLE -> SUSPENDED
D: [pulseaudio] core.c: Hmm, no streams around, trying to vacuum.
...

# Check if the "module-suspend-on-idle" module is loaded in hassio_audio:
docker exec -it hassio_audio pactl list modules
...
Module #16
	Name: module-suspend-on-idle
	Argument: 
	Usage counter: n/a
	Properties:
		module.author = "Lennart Poettering"
		module.description = "When a sink/source is idle for too long, suspend it"
		module.version = "14.2"

2 Likes

This fixed the issue. Thanks.

Dominik - phantastic! Saved me hours of debugging and frustration. Thank you.

Got to hug u… it been months i try to fix this.

Thank you very much!

Also I made actions System Daemon variant from this and it’s works!

I have hassos and just found this issue on my Pi4. The workaround is not working - I can’t copy anything to /etc/docker on host since it’s ro filesystem.
So, what next?

Can you copy and paste the system health section from the Configuration > Info page?

System Health

version core-2021.3.4
installation_type Home Assistant OS
dev false
hassio true
docker true
virtualenv false
python_version 3.8.7
os_name Linux
os_version 5.4.83-v7l
arch armv7l
timezone Europe/Warsaw
Home Assistant Community Store
GitHub API ok
Github API Calls Remaining 4932
Installed Version 1.11.3
Stage running
Available Repositories 774
Installed Repositories 10
AccuWeather
can_reach_server ok
remaining_requests 31
Airly
can_reach_server ok
requests_remaining 996
requests_per_day 1000
Home Assistant Cloud
logged_in true
subscription_expiration 13 April 2021, 2:00
relayer_connected true
remote_enabled true
remote_connected true
alexa_enabled true
google_enabled false
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Home Assistant OS 5.12
update_channel stable
supervisor_version supervisor-2021.03.6
docker_version 19.03.13
disk_total 29.0 GB
disk_used 9.6 GB
healthy true
supported true
board rpi4
supervisor_api ok
version_api ok
installed_addons File editor (5.2.0), Check Home Assistant configuration (3.6.0), Mosquitto broker (5.1.1), ESPHome (1.16.2), Samba share (9.3.1), deCONZ (6.8.0), SQLite Web (3.0.1)
Lovelace
dashboards 8
resources 2
views 12
mode storage

Hello, thanks for posting the fix. However, on my system (RPI4 with Rasbian) there is no /etc/docker/daemon.json file. What do I do in this case?

I’ve just created a new daemon.json file with 3 lines and it all worked for me! Thanks a lot again for this solution.

Mr. Weiland, respect for the sleuthing work!

I got an alert today that one of my filesystems was getting full and when I looked at it I found the hassio_audio container generated about 1GB of useless logs each day since PI day (03.14). All of the log entries relate to this issue with "Assertion 'clock_gettime(CLOCK_REALTIME, &ts) == 0' failed", it repeats every second. And yes, it also uses about 15-20% CPU time.

I quickly found this page and I am really thankful you already identified the cause, and you also found a workaround.

One question for you please, if you don’t mind: do you know which 32-bit time syscalls alpine needs if the 64-bit ones are not available? I’m asking because I’d like to configure only the hassio_audio container to have access to these (and not to all syscalls), while keeping the other containers, well, “contained”, as they currently are. It can be easily done using the " --security-opt" parameter, see “Pass a profile for a container” at Seccomp security profiles for Docker | Docker Documentation

While your approach obviously works what you did is you probably allowed all containers access to all syscalls, essentially disabling docker security capabilities for all containers. I suppose you could have instead run only hassio_audio without the default seccomp profile by using --security-opt seccomp=unconfined

But I see no reason not to go just one step further and allow hassio_audio access only to the time functions it needs, and nothing else.

[Later edit]: I managed to identify the 19 64-bit syscalls related to time - they conveniently all have “time64” in the name. So I downloaded the default.json Docker seccomp security profile and I set only those 19 syscalls to SCMP_ACT_TRACE (I left the defaultAction for all other syscalls to SCMP_ACT_ERRNO) and it works - date returns the correct value and ping works, too, and hassio_audio is not in a loop anymore.

Steps to replicate when running on raspbian:

  1. Download the default.json Docker seccomp security profile as /etc/docker/default.json
  2. Delete the following 19 lines in the file (they are not all in a single sequence like here):
                                "clock_adjtime64",
                                "clock_getres_time64",
                                "clock_gettime64",
                                "clock_nanosleep_time64",
                                "futex_time64",
                                "io_pgetevents_time64",
                                "mq_timedreceive_time64",
                                "mq_timedsend_time64",
                                "ppoll_time64",
                                "pselect6_time64",
                                "recvmmsg_time64",
                                "rt_sigtimedwait_time64",
                                "sched_rr_get_interval_time64",
                                "semtimedop_time64",
                                "timer_gettime64",
                                "timer_settime64",
                                "timerfd_gettime64",
                                "timerfd_settime64",
                                "utimensat_time64",
  1. Add the following section right below the line "syscalls": [ (the blank space at the beginning of each line is made of TABs, not spaces):
                {
                        "names": [
                                "clock_adjtime64",
                                "clock_getres_time64",
                                "clock_gettime64",
                                "clock_nanosleep_time64",
                                "futex_time64",
                                "io_pgetevents_time64",
                                "mq_timedreceive_time64",
                                "mq_timedsend_time64",
                                "ppoll_time64",
                                "pselect6_time64",
                                "recvmmsg_time64",
                                "rt_sigtimedwait_time64",
                                "sched_rr_get_interval_time64",
                                "semtimedop_time64",
                                "timer_gettime64",
                                "timer_settime64",
                                "timerfd_gettime64",
                                "timerfd_settime64",
                                "utimensat_time64"
                        ],
                        "action": "SCMP_ACT_TRACE",
                        "args": [],
                        "comment": "Invoke a ptracer to make a decision or set errno to -ENOSYS",
                        "includes": {},
                        "excludes": {}
                },
  1. Edit /lib/systemd/system/docker.service and change the line
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

to

ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --seccomp-profile /etc/docker/default.json
  1. Completely restart dockerd (or reboot, it’s simpler) and after that the hassio_audio stops (with a different error :slight_smile: ) but it’s not in a loop anymore

I wish there was a portainer option to add --security-opt seccomp=/etc/docker/default.json for a single container (i.e. hassio_audio) and not as the default for all containers but there isn’t one yet. Hopefully, soon, I saw they reopened the feature request 3 days ago:

Cheers!

BTW, this issue seems to be fixed upstream since June-July 2020 in docker 19.03.9 and libseccomp 2.4.2.
On Raspbian 10 (buster) the current version of docker is 20.10.6, however libseccomp2 is still only 2.3.3-4
Below are some pointers.

“It looks like with the release of Docker 19.03.11 this has been addressed, at least on native hardware running a 5.x kernel.
[…]
Edit: It looks like this fix is comprehensive with this new version of Docker this is no longer an issue even on a host running an old 4.x series kernel.”

FAQ - LinuxServer.io has some options:
Option 2 Manually install an updated version of the library with dpkg [please note, on gitlab alpinelinux org issue 12091 somebody mentioned “This workaround makes my Raspberry in kernel panic”]
Option 3 Add the backports repo for DebianBuster

I have some news for you folks.
With the code down below you can install buster-backports and update your raspberrys libseccomp2 to version 2.4.4-1.
I think it is the best solution and I think it makes the workaround in the docker file unnecessary…


sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138
echo "deb http://deb.debian.org/debian buster-backports main" | sudo tee -a /etc/apt/sources.list.d/buster-backports.list
sudo apt update
sudo apt install -t buster-backports libseccomp2

1 Like

Sorry to resurrect this thread but I’m noticing this issue on my Pi4.

It doesn’t seem quite as persistent as in some of the earlier threads but I noticed pulseaudio kept going between 0% and 14% every few seconds…

When I look at the hassio_audio stats it does the same:

I’m running Raspian bullseye 5.10.92-v7l+

HASS system info as below

System Health

version core-2022.3.0
installation_type Home Assistant Supervised
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.9.9
os_name Linux
os_version 5.10.92-v7l+
arch armv7l
timezone UTC
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
GitHub API Calls Remaining 4954
Installed Version 1.23.0
Stage running
Available Repositories 999
Downloaded Repositories 3
Home Assistant Cloud
logged_in false
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Raspbian GNU/Linux 11 (bullseye)
update_channel stable
supervisor_version supervisor-2022.01.1
docker_version 20.10.12
disk_total 916.8 GB
disk_used 11.3 GB
healthy true
supported failed to load: Unsupported
supervisor_api ok
version_api ok
installed_addons Mosquitto broker (6.0.1), Node-RED (11.0.4), InfluxDB (4.3.0), Grafana (7.4.1), File editor (5.3.3)
Lovelace
dashboards 1
resources 0
mode auto-gen

It’s less of an issue as it isn’t permanently stuck at high CPU but it’s certainly not great that it keeps spiking like this, any suggestions much appreciated.

Have the same exact issue as you described but, as it has not become critical until now, I have not tried it myself, but here’s the latest I found on this topic:

1 Like