[pulseaudio-discuss] [PATCH] daemon: Stop session-started PA daemon when exiting X session

[David Henningsson]

On 2014-09-16 15:09, Tanu Kaskinen wrote:
> On Tue, 2014-09-16 at 14:27 +0200, David Henningsson wrote:
>>
>> On 2014-09-15 17:09, Felipe Sateler wrote:
>>> On Mon, Sep 15, 2014 at 5:50 AM, Tanu Kaskinen
>>> <tanu.kaskinen at linux.intel.com> wrote:
>>>> On Wed, 2014-09-10 at 09:51 -0300, Felipe Sateler wrote:
>>>>> I would think the daemon is per-session, not per-user, given that
>>>>> (until systemd --user works) we cannot track user stuff across
>>>>> sessions.
>>>>
>>>> We can, module-systemd-login exists for that purpose. It creates a
>>>> client object for each session that the user has. As long as there are
>>>> any client objects in PulseAudio, the server won't shut down
>>>> automatically. When the last client exits, PulseAudio will exit after a
>>>> delay (20 seconds by default).
>>>
>>> And what happens if I log in to X, switch to a VT, logout from X and
>>> login again to X? As I understand the current status, the dbus session
>>> is tied to the X server, so there should be a new session bus in thi
>>> case. Does pulseaudio handle this situation correctly? (eg, will
>>> bluetooth devices work after this?)
>>
>> This is all tricky stuff which we'll need to sort out in some smart way.
>>
>> First, as Tanu said, Bluetooth is tied to the system bus. This causes a
>> problem of its own, given that if we have two different PA instances
>> running simultaneously as two different users, who should have access to
>> the bluetooth device(s)? Does anybody know if this handled correctly? [1]
>
> My /etc/dbus-1/system.d/bluetooth.conf has this:
>
>    <policy at_console="true">
>      <allow send_destination="org.bluez"/>
>    </policy>
>
> I'm not sure, but I think this means that only the user who has an
> active session on a seat can access the D-Bus API of BlueZ. If a user is
> actively using a BT device when switching users, however, I don't think
> PulseAudio will automatically release the device.
>
> On a multi-seat system with multiple simultaneous active users this is
> probably more broken. Something might happen on this front at some
> point, since we will have to deal with this in Tizen somehow, as we try
> to support multi-seat configurations including Bluetooth.

Ok, sounds like a plan.

>> Second, for ALSA and the mute issue, I think we need to notify PA
>> somehow that the system is going down, either for suspend, hibernate or
>> poweroff. And that needs to complete before ALSA mutes things. This has
>> nothing to do with X sessions.
>
> Does ALSA do the muting also when suspending or hibernating? I haven't
> noticed such behaviour, but then again, I haven't noticed the poweroff
> muting either...

Felipe, could you elaborate on this? I think I've seen such a mute 
script, but I'm not sure if it was upstream or debian specific, perhaps 
it's even removed these days?

>> Third, the lifetime of the PulseAudio instance should follow the
>> lifetime dictated by systemd-logind (or other login manager). This is
>> because we have our native socket in XDG_RUNTIME_DIR, i e
>> /run/user/<uid>/pulse. PulseAudio should quit before this directory is
>> removed. Also, this also dictates that we can have at most one PA
>> instance per user, otherwise they will end up overwriting each other's
>> socket files.
>
> So what do you propose? Should we not apply the Debian patch, nor tweak
> the auto-exit delay? I'm fine with either: tweak the auto-exit delay (if
> someone writes a patch) or not do anything (in which case Debian will
> have to keep patching PulseAudio until the Real Fix somehow
> materializes).

At this point, I don't have any concrete proposal. In Ubuntu, I wrote an 
inotify that kills PA whenever XDG_RUNTIME_DIR is removed [1]. But you 
did not like this patch.

Removing the 20-second delay sounds like the right thing to do, but I 
wonder if it will cause startup problems? E g, if PA autospawns, and 
there are no systemd modules or anything else keeping it alive (e g 
because the user does not run systemd), and it's waiting for a client to 
connect?

> (Some nitpicking: we can have more than one PA instance per user, if the
> extra instances are started with a different XDG_RUNTIME_DIR.)

Okay, is this something we actively support, and that we won't cause 
troubles anywhere else? (I suspect loading the esd support module won't 
work...)

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[1] 
http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-April/017015.html