I have tried:
`root@raspberrypi:~# sudo docker exec -i hassio_audio pactl load-module module-suspend-on-idle
Connection failure: Connection refused
pa_context_connect() failed: Connection refused`
I invokes command: docker ps to get the following line:
homeassistant/armv7-hassio-audio:2021.02.1
I am using method Supervised.
How to resolve it?
I see sometimes that the following is consuming high CPU:
ghcr.io/hassio-addons/appdaemon/armv7:0.4.3
Erik
Some comments on what you wrote…
You don’t need to use “sudo” if you are root already. “sudo” is a shortcut to let you execute a command as root (super user do) when you are a “normal” user.
You did not run the command with “-it”. Note the “t” for TTY. This is necessary when you execute docker exec from the command prompt (but you must exclude it when the command is executed from a shell script).
Faultfinding is about a process of elimination. First confirm that you are doing it right, by executing a “generic” command in any of your running containers. If it works, then your command is ok and you don’t have e.g. permission problems. If the same command works in one container and not the other, then there is something wrong with that container. Etc.
Can you try the following? You can run this as “pi”, you don’t need to be root.
# First just execute a generic command in the container, to see if the container itself is ok.
# This should return all the processes running within the container.
docker exec -it hassio_audio ps -ef
# If that worked ok, then list the modules that are currently loaded:
docker exec -it hassio_audio pactl list modules
# If ok then try to load the module again:
docker exec -it hassio_audio pactl load-module module-suspend-on-idle
# If you still get the same error, try to stop the hassio_audio container to reset it.
# It should be started automatically by the hassio_supervisor after a short period.
docker stop hassio_audio
# If nothing works, can you show the (full) output of the following commands?
docker images
docker ps -a
# You can also try to execute a generic command in other containers, to confirm you do it right. e.g.
docker exec -it hassio_supervisor date
Hi, I have the same problem as ErikC. I tried your command list:
~/IOTstack $ 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
570 root 0:00 s6-supervise alsa
571 root 0:00 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
3303 root 0:00 ps -ef
~/IOTstack $ docker exec -it hassio_audio pactl list modules
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
~/IOTstack $ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> e7e49e1e6869 6 minutes ago 72.4MB
iotstack_nodered latest 1919f0244bf5 45 hours ago 478MB
eclipse-mosquitto latest 23609c6b2cd6 3 days ago 8.31MB
linuxserver/mariadb latest f36d5889c9d1 5 days ago 284MB
nextcloud latest 98824f80ad84 8 days ago 697MB
homeassistant/armv7-hassio-supervisor 2021.02.11 be11a28f19e8 10 days ago 247MB
homeassistant/armv7-hassio-supervisor latest be11a28f19e8 10 days ago 247MB
amir20/dozzle latest e41221e1e064 10 days ago 10.1MB
pihole/pihole latest 1b529812cd4b 11 days ago 329MB
homeassistant/armv7-hassio-audio 2021.02.1 40f28e0fd362 13 days ago 90.5MB
homeassistant/armv7-hassio-cli 2021.02.1 468da71074dd 2 weeks ago 81MB
homeassistant/raspberrypi4-homeassistant 2021.2.3 f3839c412de8 2 weeks ago 1.01GB
homeassistant/home-assistant stable 709ad71148db 2 weeks ago 980MB
nodered/node-red latest 8e2c79a7fdee 3 weeks ago 378MB
portainer/portainer-ce latest 685b8339bd63 3 weeks ago 159MB
homeassistant/armv7-base latest 21461176cb52 3 weeks ago 72.4MB
koenkk/zigbee2mqtt latest 11cfe6ca416e 3 weeks ago 140MB
homeassistant/armv7-hassio-dns 2021.01.0 eeb0a3e43eb4 4 weeks ago 85.9MB
homeassistant/armv7-hassio-observer 2020.10.1 bf193dc8f2c4 4 months ago 71.8MB
homeassistant/armv7-hassio-multicast 3 0fbd536e8547 6 months ago 63.3MB
carldebilly/zigbee2mqttassistant latest b69b0032ff26 10 months ago 211MB
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f45cabd73267 homeassistant/armv7-hassio-audio:2021.02.1 "/init" 10 minutes ago Up 10 minutes hassio_audio
cd8e9602076f homeassistant/armv7-hassio-cli:2021.02.1 "/init /bin/bash -c …" 24 minutes ago Up 24 minutes hassio_cli
5620f60ae79a nextcloud "/entrypoint.sh apac…" 27 minutes ago Up 27 minutes 0.0.0.0:9321->80/tcp nextcloud
09adcc73a83a carldebilly/zigbee2mqttassistant "dotnet Zigbee2MqttA…" 28 minutes ago Up 27 minutes 0.0.0.0:8880->80/tcp zigbee2mqtt_assistant
cd4fa58e0ee2 koenkk/zigbee2mqtt "docker-entrypoint.s…" 28 minutes ago Up Less than a second zigbee2mqtt
68793ac43980 iotstack_nodered "npm --no-update-not…" 28 minutes ago Up 27 minutes (healthy) 0.0.0.0:1880->1880/tcp nodered
8be20402e0e8 pihole/pihole:latest "/s6-init" 28 minutes ago Up 27 minutes (healthy) 0.0.0.0:53->53/udp, 0.0.0.0:53->53/tcp, 0.0.0.0:67->67/udp, 443/tcp, 0.0.0.0:8089->80/tcp pihole
40798d511cd4 portainer/portainer-ce "/portainer" 28 minutes ago Up 27 minutes 0.0.0.0:8000->8000/tcp, 0.0.0.0:9000->9000/tcp portainer-ce
dc264dde8bea linuxserver/mariadb "/init" 28 minutes ago Up 27 minutes nextcloud_db
1a7f4611f7a5 eclipse-mosquitto "/docker-entrypoint.…" 28 minutes ago Up 27 minutes 0.0.0.0:1883->1883/tcp mosquitto
abe199f35bfa amir20/dozzle:latest "/dozzle" 28 minutes ago Up 27 minutes dozzle
c32b7674f95e homeassistant/armv7-hassio-multicast:3 "/init" 35 minutes ago Up 35 minutes hassio_multicast
217d1963bf40 homeassistant/armv7-hassio-dns:2021.01.0 "/init" 35 minutes ago Up 35 minutes hassio_dns
b0581c3dd673 homeassistant/raspberrypi4-homeassistant:2021.2.3 "/init" 41 hours ago Up 35 minutes homeassistant
01ba45b71a83 homeassistant/armv7-hassio-observer:2020.10.1 "/init" 41 hours ago Up 36 minutes 0.0.0.0:4357->80/tcp hassio_observer
c13581959592 homeassistant/armv7-hassio-supervisor "/init" 41 hours ago Up 36 minutes hassio_supervisor
da1de53da24f homeassistant/home-assistant:stable "/init" 43 hours ago Exited (0) 43 hours ago home_assistant
docker exec -it hassio_supervisor date
Sun Feb 28 11:22:59 UTC 2021
Any idea on how to get rid of this connection refused issue?
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.
Download the “seccomp” default.json file from Github:
https://github.com/moby/moby/blob/bc6f4cc7032544553d2304a5b47ba235dbfe5b9c/profiles/seccomp/default.json
Copy the file to the Home Assistant host (Raspberry Pi), and put it in /etc/docker/
Edit this newly created file, /etc/docker/default.json.
In the second line replace
"SCMP_ACT_ERRNO"
with
"SCMP_ACT_TRACE"
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",
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"
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.
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?
| 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 |
| GitHub API | ok |
|---|---|
| Github API Calls Remaining | 4932 |
| Installed Version | 1.11.3 |
| Stage | running |
| Available Repositories | 774 |
| Installed Repositories | 10 |
| can_reach_server | ok |
|---|---|
| remaining_requests | 31 |
| can_reach_server | ok |
|---|---|
| requests_remaining | 996 |
| requests_per_day | 1000 |
| 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 |
| 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) |
| 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:
/etc/docker/default.json
"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",
"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": {}
},
/lib/systemd/system/docker.service and change the lineExecStart=/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
) but it’s not in a loop anymoreI 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!