[pulseaudio-discuss] [RFC] Add configure option to specify default autospawn behavior

[Felipe Sateler]

On Mon, Dec 1, 2014 at 10:55 AM, David Henningsson
<david.henningsson at canonical.com> wrote:
>
>
> On 2014-12-01 13:33, Colin Guthrie wrote:
>>
>> Hi all,
>>
>> Felipe Sateler wrote on 01/12/14 12:23:
>>>
>>> On Mon, Dec 1, 2014 at 5:27 AM, David Henningsson
>>> <david.henningsson at canonical.com> wrote:
>>>>
>>>>
>>>>
>>>> On 2014-11-29 22:04, Felipe Sateler wrote:
>>>>>
>>>>>
>>>>> Dbus integration with systemd user sessions is not complete yet. This
>>>>> means
>>>>> that a socket-activated pulseaudio daemon will not be able to access
>>>>> the
>>>>> session
>>>>> bus, and thus breaking several modules.
>>>>>
>>>>> This means that distributions should not yet enable the systemd units
>>>>> by
>>>>> default
>>>>> until that problem is solved. However, this does not mean that the
>>>>> units
>>>>> cannot be
>>>>> provided for the users that choose to experiment with them.
>>>>>
>>>>> Therefore, I propose to separate the decision to support socket
>>>>> activation
>>>>> from the
>>>>> decision to default to autospawn or not, via a separate configure
>>>>> switch
>>>>>    --enable-autospawn-default. This way one could build socket
>>>>> activation,
>>>>> and not ship
>>>>> it by default.
>>>>
>>>>
>>>>
>>>> One could still do that behaviour by just changing autospawn in
>>>> /etc/pulse/client.conf, right?
>>>
>>>
>>> Almost. The problem is that if the user has a modified
>>> ~/.config/pulse/client.conf, or (on debian-based distros at least) a
>>> modified /etc/pulse/client.conf, they may not get the updated default.
>>
>>
>> Indeed. This kind of thing will sadly always be a problem.
>
>
> Ok, fair point.
>
>>>> It looks rather like we need to provide something that builds socket
>>>> activation but disables it? And given the problems we have with socket
>>>> activation (combined with session level D-Bus) maybe it makes sense to
>>>> default to that?
>>>
>>>
>>> I'm not quite sure what you mean by "disabling it". AFAICT, the
>>> current activation code does fall back to the normal socket opening
>>> when no FD has been passed. So you can have a socket-activated server
>>> running without socket activation.
>>
>>
>> Yeah, the build itself is fine and continues to work.
>>
>>
>> I'm not against splitting up the option here so that socket activation
>> support gets build but not used and the old autospawn behaviour can be
>> controlled - it's basically just a matter of not shipping the units (or
>> shipping them but not running the "systemctl --global enable
>> pulseaudio.socket" bit in the package scripts).
>>
>> I'd rather that the default value of PA_AUTOSPAWN_DEFAULT gets set
>> depending on HAVE_SYSTEMD_DAEMON appropriately, but I'm not that fussed
>> really.
>
>
> So, excuse me if this comes from a systemd newbie. But here's my reasoning:
>
> As of now, we have seen some reduced functionality because PulseAudio can't
> access D-Bus. (And we don't know how far D-Bus is from moving from
> per-session to per-user, so we assume the bus is per session for now.)
>
> This means that at least module-jackdbus-detect and the device reservation
> protocol are regressed. I don't know what implications the lack of
> server-lookup has. module-dbus-protocol is also broken, but that module is
> (AFAIK) still broken in other ways too.
>
> Let's then assume we think this is severe enough not to recommend people to
> use systemd activation by default, because all distros I know of have
> already removed it.
>
> Then our upstream default becomes:
>  * Ship with autospawn=yes
>  * Ship with files for enabling systemd activation
>  * Ship without "systemctl --global enable pulseaudio.socket" (if that's the
> same as building it in, but not enabling it).
>
> In essence, if we ship without "systemctl --global enable pulseaudio.socket"
> already, the only difference we need to do is to re-enable autospawning even
> if systemd activation is built in. (In an ideal world, the "systemctl
> --global enable pulseaudio.socket" should also disable autospawning...)
>
> Would that not give what Felipe is after, i e, building it in for people
> that want to experiment, but have it remain disabled?

The only difference between your proposal and my patch  is that the
default would not be configurable. But if the default is the same that
I want (autospawn = true) then I'm ok with that too :)


-- 

Saludos,
Felipe Sateler