Description of problem: When logging out from a GNOME session, the running pulseaudio daemon is killed abruptly without going through its cleanup phase, so the pidfile /tmp/pulse-$USER/pid is left in the filesystem. The leftover pidfile sometimes causes trouble on next login - pulseaudio refuses to start if a process is running with the recorded PID value. Version-Release number of selected component (if applicable): pulseaudio-0.9.10-1.fc9.x86_64 How reproducible: always Steps to Reproduce: 1. Use the default configuration. Login into GNOME. 2. Verify that pulseaudio is running (ps aux|grep pulsea). Remember its PID. 3. Logout from GNOME. 4. Switch to tty1 and login as root. 5. cat /tmp/pulse-$YOUR_USUAL_USER_NAME/pid Actual results: The pidfile is still there and it contains the PID. Notice that the process is not running anymore (ps aux|grep $PID). Expected results: The pidfile should be deleted when pulseaudio exits. Additional info: strace of pulseaudio being killed by the logout from GNOME ends with: 2546 read(35, "l\4\1\1\35\0\0\0\33\0\0\0\211\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 2048) = 189 2546 read(35, 0x114a0f0, 2048) = -1 EAGAIN (Resource temporarily unavailable) 2546 poll([{fd=4, events=POLLIN}, {fd=61, events=POLLIN}, {fd=56, events=POLLIN}, {fd=60, events=POLLIN}, {fd=51, events=POLLIN}, {fd=55, events=POLLIN}, {fd=46, events=POLLIN}, {fd=50, events=POLLIN}, {fd=41, events=POLLIN}, {fd=45, events=POLLIN}, {fd=40, events=POLLIN}, {fd=18, events=POLLIN}, {fd=25, events=POLLIN}, {fd=36, events=POLLIN, revents=POLLIN|POLLHUP}, {fd=35, events=POLLIN}, {fd=32, events=POLLIN}, {fd=28, events=POLLIN}, {fd=27, events=POLLIN}, {fd=26, events=POLLIN}, {fd=22, events=POLLIN}, {fd=15, events=POLLIN}, {fd=11, events=POLLIN|POLLERR|POLLHUP}, {fd=11, events=0}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 25, 0) = 1 2546 read(36, "", 4096) = 0 2546 write(2, "XIO: fatal IO error 11 (Prost\305\231"..., 86) = 86 2546 write(2, " after 12 requests (12 know"..., 71) = 71 2546 exit_group(1) This led me to suspect that the module module-x11-publish might be the one killing the daemon here. I have commented out the line "load-module module-x11-publish" in /etc/pulse/default.pa and the behaviour has changed. Now the pulseaudio daemon keeps running even after I logout from my GNOME session.
libX11 kills clients forcibly if the X session ends. To work around this I added module-x11-xsmp which is normally from /etc/xdg/autostart/pulseaudio-module-xsmp.desktop. It connects to the X session manager and terminates PA cleanly before the session ends. Is this module loaded properly on your setup? Also, newer PA versions check the exename for old PID files. PA should be able to detect if the PID still belongs to a PA process. Are you sure you are running the latest and greatest PA?
Something is indeed wrong with the xsmp module. I can see "PulseAudio Session Management" enabled in my Gnome session settings, but the module module-x11-xsmp is not loaded: $ pactl list|grep x11 Name: module-x11-publish Trying to load it manually does not work: $ pactl load-module module-x11-xsmp Failure: Module initalization failed Then I tried killing pulseaudio and running it again with "pulseaudio -k" and "pulseaudio". Then in another gnome-terminal I could load the module successfully: $ pactl load-module module-x11-xsmp 14 And are you sure PA checks the exename for old PID files? I don't see such a check in src/pulsecore/pid.c:pa_pid_file_create(). It only tests the presence of a process by sending it a 0 signal.
... and I looked at the current SVN checkout. On my system I am running current soon-to-be-released F9: $ rpm -qa|grep pulse gstreamer-plugins-pulse-0.9.5-0.5.svn20070924.fc9.x86_64 pulseaudio-libs-0.9.10-1.fc9.x86_64 pulseaudio-core-libs-0.9.10-1.fc9.x86_64 pulseaudio-esound-compat-0.9.10-1.fc9.x86_64 pulseaudio-libs-zeroconf-0.9.10-1.fc9.x86_64 pulseaudio-module-zeroconf-0.9.10-1.fc9.x86_64 pulseaudio-utils-0.9.10-1.fc9.x86_64 xine-lib-pulseaudio-1.1.12-2.fc9.x86_64 pulseaudio-0.9.10-1.fc9.x86_64 alsa-plugins-pulseaudio-1.0.16-4.fc9.x86_64 pulseaudio-module-x11-0.9.10-1.fc9.x86_64 pulseaudio-libs-glib2-0.9.10-1.fc9.x86_64 pulseaudio-module-gconf-0.9.10-1.fc9.x86_64
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Lennart, Your recent post to fedora-devel explained a part of the problem: > I actually did fix this issue, but not completely. PA does check the > exename of an existing PID file to check if it is actually pa that > owns the PID if it is still running. However, I added this fix only when > killing an existing daemon (i.e. -k), not when starting a new > one. It's trivial to fix. There remains the issue that module-x11-xsmp does not initialize properly (as I noted in comment #2). I get these messages in /var/log/messages: module-x11-xsmp.c: X11 session manager not running. module.c: Failed to load module "module-x11-xsmp" (argument: ""): initialization failed.
You are apparently running no session manager. In which case it is very difficult to connect to one. What kind of setup are you using? Gnome? KDE? Some homegrown wm?
I am running Gnome and I do have a session manager. From gnome-terminal: $ echo $SESSION_MANAGER local/unix:@/tmp/.ICE-unix/3217,unix/unix:/tmp/.ICE-unix/3217 But it looks like pulseaudio itself does not know about the session manager, because SESSION_MANAGER is not set in the process's environment: # grep SESSION_MANAGER /proc/`/sbin/pidof pulseaudio`/environ || echo Bad Bad
Where do you start PA from? There's something fishy going on here.
Hmm, me too. Module module-x11-xsmp didn't run (although it is in /etc/xdg/autostart/). OTOH: [root@viklef ~]# LANG=C grep -s SESSION_MANAGER /proc/`/sbin/pidof pulseaudio`/environ || echo Bad Binary file /proc/629/environ matches [root@viklef ~]# And yes, pulseaudio doesn't start after suspend/resume cycle pretty predicatbly.
Could it be because I haven't installed/upgraded F9 with anaconda, but came from Rawhide?
I just did a full install (plus yum update) of F9 on a new Acer Intel desktop machine. I have the same problem with module-x11-xsmp not loading. I did it by hand as above (killing, restarting) and was able to load it in another terminal. I also have SESSION_MANAGER set. May 31 17:16:59 localhost pulseaudio[14469]: module-x11-xsmp.c: X11 session manager not running. May 31 17:16:59 localhost pulseaudio[14469]: module.c: Failed to load module "module-x11-xsmp" (argument: ""): initialization failed.
(In reply to comment #8) > Where do you start PA from? Frankly, I'm not 100% sure how it starts nor what the expected way of starting it is. Gnome starts it somehow. I think it goes through the 'esd' wrapper script, because I have /desktop/gnome/sound/enable_esd enabled in gconf and I can see the PA process running with the arguments "/usr/bin/pulseaudio --log-target=syslog" which is consistent with what the esd script does. You might be interested in my process hierarchy as seen by pstree -Aalp: init,1 |- [...snipped irrelevant processes...] |-gdm-binary,2232 -nodaemon | `-gdm-simple-slav,3365 --display-id /org/gnome/DisplayManager/Display1 | |-Xorg,3366 :0 -br -verbose -auth /var/run/gdm/auth-cookie-[.....] | `-gdm-session-wor,3427 | `-gnome-session,3520 | |-bluetooth-apple,3616 --singleton | |- [...some other processes here...] | `-{gnome-session},3596 |- [...some more processes here...] |-gnome-settings-,3575 | |-pulseaudio,3578 --log-target=syslog | | |-gconf-helper,3582 | | |-{pulseaudio},3580 | | `-{pulseaudio},3581 | `-{gnome-settings-},3577 | `- [...more processes...] So pulseaudio is a child of gnome-settings-daemon, but it's not descended from gnome-session (Should it be? I have no idea.).
I am now sure Gnome starts PA through the esd wrapper. I verified this by removing the 'exec' in the script, so a process called esd can now be seen as a parent of pulseaudio.
Pulseaudio should be able to start up regardless of whether /tmp/pulse-$USER/pid was cleaned up on the last logout - for example, during an unclean shutdown, the cleanup might not be possible. So the startup code needs to be able to work regardless. I hope that the latest PA does in fact do this correctly, and that it gets pushed soon - it's a major pain to have to check after every login whether PA is running.
Unfortunately libX11 forcibly terminates PA if the X11 connection goes away. This is a limitation of libX11 we cannot entirely work around. The only part-workaround we have is the XSMP module which however doesn`t get loaded in some situations (such as KDE). The proper fix is to make sure that PA properly handles left-over PID files. bug #438284 is about that. To fix that bug I have now uploaded a fixed package for F9: http://admin.fedoraproject.org/updates/pulseaudio-0.9.10-2.fc9 I am now closing this bug, because it is unfixable with current libX11 and this updated package at least fixes the negative effects of it.