(Solved) amixer: Mixer attach pulse error: Connection refused

Forum rules
Before you post please read how to get help
Post Reply
Matthew_Wai
Level 4
Level 4
Posts: 425
Joined: Sun Jun 07, 2015 10:42 am
Location: China

(Solved) amixer: Mixer attach pulse error: Connection refused

Post by Matthew_Wai » Fri Jun 28, 2019 10:06 am

Code: Select all

matthew@pc:~$ cat /lib/systemd/system-sleep/Restart_audio
#!/bin/bash
case $1 in
post)       
amixer -q -D pulse sset Master toggle
sleep 1s
amixer -q -D pulse sset Master toggle
;; 
esac
The above has resulted in the following:

Code: Select all

Jun 28 21:51:07 pc systemd-sleep[25511]: ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused
Jun 28 21:51:07 pc systemd-sleep[25511]: amixer: Mixer attach pulse error: Connection refused
Jun 28 21:51:08 pc systemd-sleep[25511]: ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused
Jun 28 21:51:08 pc systemd-sleep[25511]: amixer: Mixer attach pulse error: Connection refused
Jun 28 21:51:08 pc (sd-executor)[25689]: /lib/systemd/system-sleep/Restart_audio failed with exit status 1.
How can I solve the "Connection refused" problem?
When I manually run /lib/systemd/system-sleep/Restart_audio post via Terminal, it works.
I need "Restart_audio" because: viewtopic.php?f=49&t=296845#p1652003
Last edited by Matthew_Wai on Sat Jun 29, 2019 6:29 am, edited 1 time in total.

rene
Level 12
Level 12
Posts: 4152
Joined: Sun Mar 27, 2016 6:58 pm

Re: amixer: Mixer attach pulse error: Connection refused

Post by rene » Fri Jun 28, 2019 1:19 pm

Probably/possibly by prefixing the amixer commands with sudo -u matthew or sudo -i -u matthew. I.e., systemd-sleep scripts run as root and Pulseaudio runs as your user, problematic in the same manner as most of the other issues you've posted. Untested, and might need some specific bit of environment, but try...

Matthew_Wai
Level 4
Level 4
Posts: 425
Joined: Sun Jun 07, 2015 10:42 am
Location: China

Re: amixer: Mixer attach pulse error: Connection refused

Post by Matthew_Wai » Sat Jun 29, 2019 3:29 am

sudo -u matthew works. Thank you!
rene wrote:
Fri Jun 28, 2019 1:19 pm
Pulseaudio runs as your user
Could you explain "Pulseaudio runs as your user"? Did you mean the commands were actually run by the user "PulseAudio" rather than "matthew", resulting in "Connection refused"?

rene
Level 12
Level 12
Posts: 4152
Joined: Sun Mar 27, 2016 6:58 pm

Re: (Solved) amixer: Mixer attach pulse error: Connection refused

Post by rene » Sat Jun 29, 2019 9:52 am

Matthew_Wai wrote:
Sat Jun 29, 2019 3:29 am
sudo -u matthew works. Thank you!
rene wrote:
Fri Jun 28, 2019 1:19 pm
Pulseaudio runs as your user
Could you explain "Pulseaudio runs as your user"? Did you mean the commands were actually run by the user "PulseAudio" rather than "matthew", resulting in "Connection refused"?
No, I mean that your Pulseaudio instance is run by user "matthew" whereas the system-sleep script is run by user "root". Latter user has, like any other user, no access to matthew's Pulseaudio instance.

Note that this is the same issue as with several of your previous inquiries: trying to control/restart a service that runs in user context from system context, from processes run by "root". As users go user "root" is clearly special, but in situations like this really only by having the capability to pretend to be any other user, i.e., such as through mentioned sudo -u matthew.

Rest is not really important, but to get down to specifics here....

Audio on Linux is controlled by ALSA which comprises kernel-based hardware drivers and lowlevel "coreware", together with userspace-based middleware in the form of libasound. Pulseaudio then layers itself on top of latter as "higher middleware", presenting the final audio API to applications. When Pulseaudio was new, applications still spoke directly to libasound rather than the Pulseaudio API and to still have these applications use Pulseaudio, Pulseaudio also presents an alternative libasound API emulation in the form of the libasound "pulse" plugin that your amixer -D pulse commands are using. I.e., amixer is using the libasound API directly but has by going through the "pulse" plugin its commands translated to Pulseaudio commands. Which may then in nice circular manner eventually end up again as libasound commands, but this time as controlled by Pulseaudio, and as part of its normal layering on top of libasound.

In any case, and although I haven't in fact checked specifics here, I expect that mentioned "pulse" plugin communicates with your Pulsaudio daemon over the D-Bus session bus and that this is where those "connection refused" messages most directly stem from: the plugin attempting to communicate over a non-existent session bus for user "root" rather than the one for user "matthew" on which your Pulseaudio daemon in fact listens.

Note that while generally it would be considered a user isolation / security issue that user "foo" doesn't have access to resources owned by user "bar", it's in the case of "foo" being "root" of course more a simple matter of the environment of user "bar" not being sanely available other than from processes owned by user "bar". That is, such as through running the needed commands with sudo -u bar as here.

Note finally that the above implies you again using a rather round-about and layering-wise wrong method to do what it is you need doing. That you'd preferably use Pulsaudio commands directly though pactl or pacmd rather than detouring through amixer. I'll leave it up to you to find out exactly which pactl commands though; those of us of particular Linux-vintage tend to not enjoy Pulseaudio much. You'll in any case still need the sudo -u bit...

Post Reply

Return to “Scripts & Bash”