Bug 484969

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.

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?

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?

"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

"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.

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.

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.

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

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.

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?

(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.

What version do you have installed on the server?

* Wed Apr 22 2009 Warren Togami <wtogami> 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.

(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.

OK, I guess that is a separate bug in pulseaudio.  It really should kill itself when the session dies.

(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?

Hmm, got no response. Closing. Feel free to reopen if thereis a bug in PA here.