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

David Henningsson david.henningsson at canonical.com
Tue Sep 16 05:27:26 PDT 2014



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:
>>> On Wed, Sep 10, 2014 at 6:18 AM, David Henningsson
>>> <david.henningsson at canonical.com> wrote:
>>>>
>>>>
>>>> On 2014-04-13 20:21, Balint Reczey wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> This patch has been contributed through Debian's bug tracker.
>>>>> Please review it and consider accepting it to the project's code base if
>>>>> you find it useful.
>>>>>
>>>>> Thanks,
>>>>> Balint
>>>>
>>>>
>>>> Hi Balint,
>>>>
>>>> I wonder if the above can cause a problem if:
>>>>
>>>>   1) User starts X session + PulseAudio
>>>>   2) The same user switches to something else (e g, a VT or SSH session),
>>>> logs in, and starts using the PA daemon
>>>>   3) User logs out of X session
>>>>
>>>> Now PulseAudio is killed, while still being in use by the user.
>>>
>>> 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]

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.

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.


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

[1] I admit I'm too lazy to check myself.


More information about the pulseaudio-discuss mailing list