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
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
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
rather than detouring through
. I'll leave it up to you to find out exactly which
commands though; those of us of particular Linux-vintage tend to not enjoy Pulseaudio much. You'll in any case still need the