Description of problem: Pulse starts on login even if it has already been started as a system daemon. Version-Release number of selected component (if applicable): latest rpm -q pulseaudio pulseaudio-0.9.15-11.fc11.x86_64 Steps to Reproduce: 1. start PA as system daemon 2. log in to X 3. pulse starts twice, some chaos ensues Additional info: To fix this bug, add the last line of this in /usr/bin/start-pulseaudio-x11 --------------- cut here 8< ------------- # Exit without running pulseaudio daemon if this is a remote desktop session [ -n "$PULSE_SERVER" ] && exit 0 ps ax | grep -v 'grep' | grep -q 'pulseaudio --system' && exit 0 ---------------------------------- The last line is enough to not start PA twice. Some of us do not have the luxury of setting PULSE_SERVER var because the server is local, not remote. this is the event.d script used to start pulse on this machine (which has set client.conf to use a systemwide daemon): -------------------------------------- cat /etc/event.d/pulseaudio start on runlevel [2345] stop on runlevel [016] exec pulseaudio --system --realtime --log-target=syslog respawn description "PulseAudio system server" pre-start script for a in `seq 60` ; do sleep 1 killall -0 hald && killall -0 dbus-daemon && break done end script post-start script ( sleep 1 ; /usr/local/bin/swift -n Allison "Welcome, Rudd O. The sound subsystem is up and running." ) & end script -------------------------- pa is used system-wuide here because there are some system events reported by a separate text-to-speech daemon, and if another user-level pa has the audio gear open, then the events never get reported.
Uh. In Fedora we install PA as session daemon. We don't really support running it as system daemon, for a number of reasons. *** This bug has been marked as a duplicate of bug 461546 ***
> Uh. In Fedora we install PA as session daemon. > We don't really support running > it as system daemon, for a number of reasons. Ater some months ago since https://bugzilla.redhat.com/show_bug.cgi?id=461546 the question is the same: why? I have running it as systemwide-daemon and it works It works for background-services as for local users The only problem is i have to login local per gui After the login i have to call the following script (no matter locally or even in ssh-session, it neeeds any local gui-login) After that you can logout, change the local user, switch to tty or whatever you want and everybody has sound, can use "sonata" to pause mpd and hear some stream or whatever. I think it would be important to get pulseaudio working systemwide as default and solve the couple of problems in the affected apllications, what you do with per-user is a dirty workaround but never the final-solution for a DAEMON #!/bin/bash killall pulseaudio 2> /dev/null /sbin/service pulsed restart 2> /dev/null sleep 1 /sbin/service mpd restart 2> /dev/null /usr/bin/mpc play
(In reply to comment #2) > > Uh. In Fedora we install PA as session daemon. > > We don't really support running > > it as system daemon, for a number of reasons. > > Ater some months ago since https://bugzilla.redhat.com/show_bug.cgi?id=461546 > the question is the same: why? It's mostly due to security, but also because all the policy logic is intended to be per-user. For security reasons we need to disable quite a bit functionality if we cannot trust the connecting user. SHM memory transfer is one of those features. Then, stuff like BT and so on relies on a proper session to be available, because auth creds are user-specific data. And so on, and so on. The system mode is intended to be used on systems like thin clients, where there is no proper local user. It's not intended to be use on normal desktops. If you want to shoot yourself in the foot, you are welcome to, but please, don't ask me to pull the trigger for you. If you want to use PA in system mode, do so, but please don't ask us to support that in Fedora.
Lennart, I understand what the motivations were, and I am completely on board with disabling e.g. SHM, but not the BT functionality. For that, you CAN trust the pulse user which is system-created and with al the PA safeguards, not likely to be invaded by regular users and, at best, the worst thing that could happen is that the BT device gets captured by PA, which was the point of it all in the beginning, right? Besides, what do YOU care if I run PA in system mode? As you have said it well, it's my security problem, not yours, right? So why is the system bus denying access to pulse when it wants to access the BlueZ stack? It should be ALLOWED at least for the system pulse user, and THAT won't affect PA or weaken system security when runnning it as user, as per the default. So really, there is NO reason to disallow access to the BT stack for the pulse user. Lennart, I'm not asking you to *support* PA in system mode. All I'm asking is for you guys to show us a significant minority of users a bit of consideration and ship PA with access to the BT bus endpoint. If you do that, there is no net negative effect for the supported user-mode configuration anyway, so not doing it is really not a "security consideration" but more of a whim.
(In reply to comment #4) > Lennart, > > I understand what the motivations were, and I am completely on board with > disabling e.g. SHM, but not the BT functionality. For that, you CAN trust the > pulse user which is system-created and with al the PA safeguards, not likely to > be invaded by regular users and, at best, the worst thing that could happen is > that the BT device gets captured by PA, which was the point of it all in the > beginning, right? I already pointed out elsewhere that the BT issue is a D-Bus permission issue that needs to be fixed in BlueZ, not PA. > Besides, what do YOU care if I run PA in system mode? I don't, just read what I wrote about "shooting yourself in the foot". > As you have said it > well, it's my security problem, not yours, right? So why is the system bus > denying access to pulse when it wants to access the BlueZ stack? Don ask me, ask the bluez packagers.