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

[Felipe Sateler]

On Mon, Sep 15, 2014 at 12:09 PM, Felipe Sateler <fsateler at debian.org> 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?)
>
>
>
>>
>>> But the core reason this patch is applied is that if pa is shutdown
>>> after alsa, pa will store a volume of 0 (as alsa shutdown mutes all
>>> the cards), so on reboot you have a 0 volume desktop. I think this is
>>> a worse outcome than the alternative, as it is terrible for
>>> accesibility.
>>
>> Why does PulseAudio shut down after alsa?
>
> I don't know how this goes now that most people are switching to
> systemd. But in the old sysvinit days, the pulseaudio process would be
> left running after X ended. If X was terminated due to system
> shutdown, there is a possibility that the ALSA shutdown script will
> run with the pulseaudio daemon running, which will mute the devices.
> After that, the pulseaudio process is terminated by the general system
> process killer. Since pulseaudio noticed the muting done by the ALSA
> script just earlier, it stores that in its database, resulting the
> muted-at-boot problem on the next boot.
>
>> Could this be solved by
>> changing the auto-exit delay from 20 seconds to zero?
>
> Probably, depending on the level of parallelization achieved by
> systemd. Assuming that the logind client exits at the same time X is
> exiting, and that systemd does not shutdown system services until X
> has finished exiting, the problem should be avoided. If the assumption
> doesn't hold, then the race still exists although less likely.
>
> Thinking about this, I don't really see a big difference between
> "exiting with the X server" and "exiting with the user session". Both
> should kill pulseaudio sufficiently early.

And I forgot to add: but this will not work on non-systemd systems, so
an alternative solution for them is needed as well.


-- 

Saludos,
Felipe Sateler