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>
) but it’s not in a loop anymore
