Bug 484969 - pulseaudio daemon fails to die when the session dies
pulseaudio daemon fails to die when the session dies
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: pulseaudio (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-10 17:03 EST by John Ellson
Modified: 2009-07-27 19:02 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-27 19:02:47 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 John Ellson 2009-02-10 17:03:19 EST
Description of problem:
After students login to ltsp clients, the later logout, each userid leaves two processes hanging around on the server. After a day of school thats a lot of processes.

    zoes     19319  0.0  0.0 268896  3328 ?        Ssl  09:53   0:00 /usr/bin/pulseaudio --start
    zoes     19357  0.0  0.0  59680  2204 ?        S    09:53   0:00 /usr/libexec/pulse/gconf-helper


   indigos  17167     1  0 09:52 ?        00:00:00 /usr/bin/pulseaudio --start
   indigos  17193 17167  0 09:52 ?        00:00:00 /usr/libexec/pulse/gconf-helper

Occasionally, but not for every user,  there are other processes seen hanging around:
    zoes     19229  0.0  0.0 125284  2260 ?        S    09:53   0:00 /usr/bin/gnome-keyring-daemon --foreground --components=keyring

    justinaa 27842  0.0  0.1 370512  6608 ?        Sl   10:25   0:00 /usr/libexec/evolution-data-server-2.24 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=3


Version-Release number of selected component (if applicable):
ltsp-server-5.1.58-1.fc10.x86_64
pulseaudio-0.9.14-1.fc10.x86_64

How reproducible:
100% for the pulse-related processes

Steps to Reproduce:
1. login from ltsp client
2. logout
3.
  
Actual results:
Processes left hanging around forever.

Expected results:
No processes for user after user logs out.

Additional info:
Comment 1 Warren Togami 2009-02-10 20:48:56 EST
Does this actually cause any actual problems?  In my experience they all eventually die.  Do they not after a few hours?

There is nothing we can do about this because it requires modifying gnome-session's default configuration to stop it from starting this pulseaudio daemon that we do not use.
Comment 2 John Ellson 2009-02-10 22:13:47 EST
I've seen no evidence that these processes ever terminate.   Right now there
are 29*2 plus a few others, 8 hours after the school closed.
(Uptime is only 27hours at the moment.  I can check this again tomorrow.)

We have 54 students.   So what damage does 100+ dead processes do? 

Can we change gnome-session's configuration somehow?  Or remove some unused rpm?
Comment 3 Warren Togami 2009-02-10 23:20:38 EST
Mmm... I'm not exactly sure how to edit gnome-session's config.  The thing is, if you disable pulseaudio startup then you will have no sound and a somewhat broken desktop if you login to the server with GNOME.

We might be forced to ship a hack script that runs in cron every 30 minutes and kills those processes under certain conditions, like if their parent processes don't look right.

What are the parent processes of the longest living pulseaudio and gconf-helper?
Comment 4 John Ellson 2009-02-11 06:04:03 EST
"ps axjf"   (is that what you mean?) shows:

    1  3403  3403  3403 ?           -1 Ssl    500   0:00 /usr/bin/pulseaudio --start
 3403  3430  3403  3403 ?           -1 S      500   0:00  \_ /usr/libexec/pulse/gconf-helper
Comment 5 John Ellson 2009-02-11 06:13:55 EST
"ps axjf"   (is that what you mean?) shows:

    1  3403  3403  3403 ?           -1 Ssl    500   0:00 /usr/bin/pulseaudio --start
 3403  3430  3403  3403 ?           -1 S      500   0:00  \_ /usr/libexec/pulse/gconf-helper




I already have a cron job that runs late at night to "killall gnome-session"
I can add "killall pulseaudio";   Not very elegant, but it should help.
Comment 6 Warren Togami 2009-02-11 10:11:36 EST
1  3403  3403  3403 ?           -1 Ssl    500   0:00 /usr/bin/pulseaudio

The leftmost one is the parent process.  Since gnome-session was killed, pulseaudio reparented itself to its parent or its parent's parent all the way back to init.

A cron script could selectively kill pulseaudio if it doesn't have an appropriate parent process.  OTOH, let's ask Lennart if there is anything that can be done in pulseaudio first.
Comment 7 Lennart Poettering 2009-02-24 21:00:15 EST
PA is actually more a "user daemon" then a "session daemon". If a single user logs in more than once it will share a single PA instance. PA is a bit of a special case here. The effect of this is that it will *not* adhere to the usual session cycles.

The default configuration of PA makes PA stay around as long as the user that started it is logged into at least one XSMP session or the user is logged in at least on one console (according to consolekit), or at least one application is using it. When the last XSMP/ConsoleKit session goes away and all connections are terminated PA will terminate itself after a short timeout.

If you send PA a SIGHUP it should dump its current state to syslog. Check for the list of clients in there. It should tell you why PA didn't terminate.

Hmm, given that this is LTSP it might actually be that --exit-idle-time=0 is set? If so, then you need to terminate PA explicitly by passing -k and you can ignore all what I wrote above.
Comment 8 John Ellson 2009-02-24 22:30:06 EST
This is what I see in /var/log/messages after a sighup to the pulseaudio process of a logged-out user.

I don't see any "clients" here?





Feb 24 22:23:18 sol pulseaudio[31979]: main.c: 1 sink(s) available.
Feb 24 22:23:18 sol pulseaudio[31979]: main.c:     index: 0
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011name: <auto_null>
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011driver: <modules/module-null-sink.c>
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011flags: DECIBEL_VOLUME LATENCY 
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011state: SUSPENDED
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011volume: 0: 100% 1: 100%
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011muted: no
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011current latency: 0.00 ms
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011configured latency: 0.00 ms; range is 4.00 .. 2000.00 ms
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011max request: 344 KiB
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011max rewind: 344 KiB
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011monitor source: 0
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011sample spec: s16le 2ch 44100Hz
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011channel map: front-left,front-right
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011used by: 0
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011linked by: 0
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011module: 7
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011properties:
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: device.description = "Null Output"
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: device.class = "abstract"
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: 1 source(s) available.
Feb 24 22:23:18 sol pulseaudio[31979]: main.c:     index: 0
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011name: <auto_null.monitor>
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011driver: <modules/module-null-sink.c>
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011flags: DECIBEL_VOLUME LATENCY 
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011state: SUSPENDED
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011volume: 0: 100% 1: 100%
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011muted: no
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011current latency: 0.00 ms
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011configured latency: 0.00 ms; range is 4.00 .. 2000.00 ms
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011max rewind: 0 KiB
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011sample spec: s16le 2ch 44100Hz
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011channel map: front-left,front-right
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011used by: 0
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011linked by: 0
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011monitor_of: 0
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011module: 7
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: #011properties:
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: device.description = "Monitor of Null Output"
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: device.class = "monitor"
Feb 24 22:23:18 sol pulseaudio[31979]: main.c: 0 sink input(s) available
Comment 9 Warren Togami 2009-02-25 00:10:00 EST
Lennart, you misunderstand this bug report.  The leftover pulseaudio processes are on the terminal servers, launched per-user by gnome-session that was launched via ssh login.
Comment 10 Lennart Poettering 2009-02-26 10:57:48 EST
Ah, so then the bug is more along the lines that PA is should not be started by gnome-session for remote displays?

That one should be easy to fix. /usr/bin/start-pulseaudio-x11 should be changed not to run PA for non-local displays. 

Hmm, I am not sure how to detect if $DISPLAY points to a non-local display. Any suggestions?
Comment 11 Jan Pazdziora 2009-07-02 13:35:15 EDT
(In reply to comment #1)
> Does this actually cause any actual problems?  In my experience they all
> eventually die.  Do they not after a few hours?

I've seen the exact same behaviour (pulseaudio and pulse/gconf-helper left running after logout) on my Fedora 11, on local, gdm logins. It poses a problem with pam_mount because that pulseaudio proces has stuff open in user's home directory, preventing pam_mount from umounting the home. Which kinda defeats the purpose of crypting the home. In my case, the process seems to end eventually but it's already too late for pam_mount.

If there is a real reason why pulseaudio should keep running after session ended, can we at least make it optional, so that in setups like this, it can be disabled?

Let me know if I should submit exact package versions / config / anything else.
Comment 12 Warren Togami 2009-07-02 16:17:45 EDT
What version do you have installed on the server?

* Wed Apr 22 2009 Warren Togami <wtogami@redhat.com> 0.9.15-11
- Bug #497214
  Do not start pulseaudio daemon if PULSE_SERVER directs pulse elsewhere.

It is no longer running for LTSP client logins for me.
Comment 13 Jan Pazdziora 2009-07-03 01:58:58 EDT
(In reply to comment #12)
> What version do you have installed on the server?

If the question is directed to me -- I don't use ltsp. I just login locally from gdm. And I was trying to bring in another perspective to why it is not always good approach to leave pulseaudio running after the session has ended. Seeing this bugzilla is still in NEW state, I thought some additional changes are still planned.
Comment 14 Warren Togami 2009-07-03 02:12:32 EDT
OK, I guess that is a separate bug in pulseaudio.  It really should kill itself when the session dies.
Comment 15 Lennart Poettering 2009-07-22 19:56:13 EDT
(In reply to comment #14)
> OK, I guess that is a separate bug in pulseaudio.  It really should kill itself
> when the session dies.  

No it shouldn't. See comment #7.

I don't see any issue in PA here. May I close this?
Comment 16 Lennart Poettering 2009-07-27 19:02:47 EDT
Hmm, got no response. Closing. Feel free to reopen if thereis a bug in PA here.

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