| Summary: | "refusing to start/autospawn" with multi-user setup | ||
|---|---|---|---|
| Product: | PulseAudio | Reporter: | Rodrigo <rodrigo> |
| Component: | daemon | Assignee: | pulseaudio-bugs |
| Status: | RESOLVED FIXED | QA Contact: | pulseaudio-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | lennart, rodrigo |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Rodrigo
2016-02-15 22:51:25 UTC
So userA and userB run in the same graphical login session? I suppose you want to use the same audio hardware for both users. Starting separate pulseaudio servers will likely cause problems, because both pulseaudio instances can't use the sound card at the same time. Therefore, I think it's best to use only one pulseaudio instance, just like you use only one X instance.
userB doesn't have access to /run/user/1000/pulse/native, which is why userB tries to start its own pulseaudio instance. And even if userB has access to the socket, pulseaudio will reject the connection attempt by a different user. There are a few steps to make this work:
Copy /etc/pulse/default.pa to /home/userA/.config/pulse/default.pa and change this line
load-module module-native-protocol-unix
to
load-module module-native-protocol-unix auth-anonymous=true
After that change anyone having access to the socket will be allowed to connect. Then give userB access to /run/user/1000/pulse/native (setfacl can probably be used to grant access to only that user, but I don't know the exact command).
It's probably also a good idea to not rely on the x11 property to point userB to userA's pulseaudio socket, so you can add "default-server = /run/user/1000/pulse/native" to /home/userB/.config/pulse/client.conf (I'm assuming that userB is only used from within userA's login sessions, so we don't need to support the case where userB logs in separately).
Thanks! I didn't know that with 2 pulseaudio they won't be allowed to user the sound card at the same time. I reported the bug because this *used* to work (i.e. creating 2 pulseaudio). But, with that restriction, I'm fine doing it this way if this setup is supported =) Also, your assumption is correct. userB is only used within userA's login sessions. But, I tried those steps, and keeping the /etc/xdg/autostart/pulseaudio.desktop file and it doesn't work. I run firefox, or a an aplay command, and audio doesn't work. I did exactly those steps, when running (as userA): $ sudo -u userB -- aplay /usr/share/sounds/alsa/Front_Center.wav It fails with: ALSA lib pcm_dmix.c:1029:(snd_pcm_dmix_open) unable to open slave aplay: main:722: audio open error: No such file or directory Nothing new in syslog when I run this, so not sure what info do you need. Permissions on /run/user/1000/pulse/native are srwxrwxrwx+ (I also added the acl, just in case pulse, but nothing changed). I'm sorry this is probably not enough to debug, but what other info can I give you? Thanks a lot! Rodrigo Oh, wait, it was a silly mistake. It was because the parent folders, /run/user/1000/ and /run/user/1000/pulse/, weren't readable by userB. But /run/user/1000 is a tmpfs, I'm not sure how to change these permissions easily. Do you know? If it's not possible, I'm not sure this is a solution :-/ I mean, how to change the permissions in a way that works across reboots I thought you already had some xhost command that you have to run every time? Setting up the pulseaudio permissions wouldn't be any more inconvenient. Maybe I'm misunderstanding something. I'd like this to be way more simple, so it doesn't break so easily, but good point. I can do that and it works. Thanks! I guess, then, that a new pulseaudio fails to start is not a bug, but a bugfix/feature, right? :) I don't actually know why it stopped working, unless you upgraded from a very old version. I don't think there have been any relevant changes in this area for a while. If you wish to have the socket somewhere else, you can pass socket=/somewhere/else to module-native-protocol-unix the same way you pass auth-anonymous=true. Great, thanks a lot! :-) |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.