Bug 444684 - pulseaudio doesn't cleanup on logout from GNOME
pulseaudio doesn't cleanup on logout from GNOME
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pulseaudio (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-29 20:19 EDT by Michal Schmidt
Modified: 2009-06-27 11:45 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-10 15:06:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Schmidt 2008-04-29 20:19:50 EDT
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.
Comment 1 Lennart Poettering 2008-05-02 10:31:37 EDT
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?
Comment 2 Michal Schmidt 2008-05-03 07:46:55 EDT
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.
Comment 3 Michal Schmidt 2008-05-03 07:48:56 EDT
... 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
Comment 4 Bug Zapper 2008-05-14 06:24:27 EDT
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
Comment 5 Michal Schmidt 2008-05-20 07:01:45 EDT
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.
Comment 6 Lennart Poettering 2008-05-27 15:10:57 EDT
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?
Comment 7 Michal Schmidt 2008-05-27 15:28:42 EDT
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
Comment 8 Lennart Poettering 2008-05-29 13:09:56 EDT
Where do you start PA from? There's something fishy going on here.
Comment 9 Matěj Cepl 2008-05-30 06:29:00 EDT
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.
Comment 10 Matěj Cepl 2008-05-30 06:29:40 EDT
Could it be because I haven't installed/upgraded F9 with anaconda, but came from
Rawhide?
Comment 11 Dan O'Brien 2008-05-31 17:22:22 EDT
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.
Comment 12 Michal Schmidt 2008-06-06 06:22:55 EDT
(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.).
Comment 13 Michal Schmidt 2008-06-06 06:27:06 EDT
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.
Comment 14 Andre Robatino 2008-09-04 07:46:56 EDT
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.
Comment 15 Lennart Poettering 2008-09-10 15:06:00 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.