Hi, Sorry for the crazy late reply. 'Twas brillig, and Neil Bird at 09/06/12 00:39 did gyre and gimble: > I've posted this in the Fedora list and googled around without > success, so this is my next stop. > > Long story short, I have Fedora 16, upgraded from F14 (and earlier), > but pulseaudio is not running (or dying) for the gdm+gnome-shell > session, although it *really* wants it. All normal users are fine. So pulseaudio is not running for gdm? It could be that it tries to startup but fails. I do remember seeing a while back a problem that gdm wasn't able to access bluetooth via dbus for some reason and this actually stopped PA starting as gdm. Might be unrelated however. If you turn up PA logging, it should tell you the necessary info. > The side effect is that, some while after logging in, or possibly as I > switch users, I get an entry in /var/log/messages every few seconds > about a pulseaudio authorisation error. I believe I have tracked these > down to gdm's gnome-shell & gnome-settings-daemon trying to talk to *my* > login's pulseaudio (as it's the first login and is sitting on the > default port?). Interesting. The connection code may indeed try localhost as a fallback but it's odd that it's not connecting to it's own PA daemon. Has it's own PA daemon exited by this stage? > Unlike my freshly-installed laptop, and the VM I created to test it, I > don't seem to have one run from start-up, although it might be stopping > before or as I log in. I'm not sure, but certainly with recent gdm's and PA's I do happily get PA running. There is some talk of not running it due to the startup delay it introduces (what with all the probing) especially as the there is no login-ready sound by default these days. > I've tried running pulseaudio manually as gdm, but it seems to just > exit by its own volition. I'm running strace again on a daemon I've run > up now. I tried earlier today from my laptop but couldn't see anything > but a seeming deliberate clean exit. It doesn't automatically respawn > like I'd expect. There were several issues in session handling in PA where gdm had a kind of deadlock with the logind module in PA. Those were issues really in systemd which I fixed in recent versions, but I'm not sure they would be to blame on a F16 setup, so likely not related. > I've even copied the X11-start-pulseaudio .desktop file into gdm's > autostart directory, and this seems to (usually) work from power up (I > actually get an audio icon in gdm's gnome-shell's panel that makes a > sound) but it goes when gdm's pulseaudio does, which I *think* is when I > first log in. Actually I'm pretty sure GDM shouldn't run this script. It will inject variables into the root window that might confuse your logged in users after it hands the X11 root window over to them. > Has anyone got any ideas as to where I should start looking at this? > What's *supposed* to start pulseaudio? I replaced pulseaudio in my > test VM with a script that would do a ps and then run the real > pulseaudio, and that indicates that it's gnome-settings-daemon that's > spawning the pa exe, but I can't find anything explicit in the gsd source. Pulseaudio autospawns itself when it's needed so it's in the libpulse code. By trying to connect to a PA daemon that is not running, g-s-d's use of the libpulse code will trigger the autospawn. > I'm running the rtkit daemon, I have gdm in the pulse-rt and > pulse-access groups (along with all local users), and I *don't* have > anyone in the audio group (which I think causes lock problems). OK, so the pulse-rt group is not needed with rtkit ad the pulse-access group is only relevant for system-wide daemons, so again it's not relevant here. > I am having random rhythmbox lock-up issues which may or may not be > related, and I *used* to have a problem with gdm locking pulseaudio out > (such the my user account could often not access sound), so I tried a > couple of fixes at the time to stop gdm trying to make sounds. I > *think* I've undone these, but may have something stray hanging about. I > can't see anything in files, gconf or dconf, though. If you've previously added any users to the audio group that will generally mess things up, but it shouldn't result in actual connection issues and authentication failures. Useful debug info would be: ps aux | grep pulseaudio xprop -root | grep PULSE_ | grep -v PULSE_COOKIE I guess the most interesting bit is why launching via gsd+autospawn didn't work. Certainly I don't have issues with that here with newer gsd+PA, so it's perhaps a problem that has just "gone away" now :s Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
