[pulseaudio-discuss] [PATCH 7/8] launch: Disable autospawn by default when systemd daemon support is enabled.

[Felipe Sateler]

On Tue, Nov 4, 2014 at 3:39 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> Felipe Sateler wrote on 03/11/14 20:28:
>> On Mon, Nov 3, 2014 at 1:30 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>>> Felipe Sateler wrote on 03/11/14 12:55:
>>>> Hi,
>>>>
>>>> I'm replying to this message but I the general question is a bit
>>>> broader than just this default.
>>>>
>>>> On Mon, Nov 3, 2014 at 6:42 AM, Colin Guthrie <colin at mageia.org> wrote:
>>>>> When enabled, this method is prefered over pulseaudio's built in
>>>>> systems so we should try our best to ensure that it cannot be spawned
>>>>> outside of the mechanisms desired.
>>>>>
>>>>> Packagers should call 'systemctl --global enable pulseaudio.socket' to
>>>>> enable the socket for all users, or alternatively ship an enabling
>>>>> symlink in /usr/lib/systemd/user/sockets.target.wants/ folder. It may
>>>>> also make sense for distributions to add in a ConditionNNN= line to the
>>>>> socket unit if they have a downstream mechanism for enabling or
>>>>> disabling pulseaudio.
>>>>>
>>>>> If individual users wish to opt out of this vendor (or administrator)
>>>>> decision, they can call 'systemctl --user mask pulseaudio.socket'
>>>>
>>>> Some of the vendors (like debian) need to support both systemd and
>>>> non-systemd usage, which needs to be detected at runtime.
>>>
>>> In this case, I'd recommend going with the lowest common denominator,
>>> that is, using PA's own autospawn.
>>>
>>> Supporting multiple init systems is really hard and I'd suggest that
>>> using different mechanisms all through the stack would make your test
>>> matrix very large.
>>
>> Yes. But I'd rather give the better mechanism by default. While I'm
>> all for supporting diversity, I don't think playing
>> lower-common-denominator is the way to build a high quality
>> distribution.
>
> Cool, well, in that case there are still options (see below).
>
>>> With that in mind, if you're dealing with non-systemd setups at all, I'd
>>> use the same mechanisms for both and at least cut down on the need for
>>> testing different approaches there (and this rules out various things
>>> when dealing with bug triaging etc).
>>>
>>>> This patch
>>>> makes the default configured at build time, which is undesirable.
>>>> Moreover, in combination with the --start patch it leaves non-systemd
>>>> users with no pulseaudio started at login.
>>>
>>> AFAIU, the --start patch was applied downstream already. Certainly it
>>> was applied in Ubuntu and I checked with David regarding that one. I
>>> didn't specifically check Debian however.
>>
>> No, we didn't disable that.
>
> Well, I *think* it'll work OK assuming you also (typically) left
> autospawn on. The fact it was disabled on Ubuntu gives some degree of
> confidence that it should be fine generally for everyone :D
>
> So I don't think this line would need to change if you switched from
> PA-autospawn to systemd socket-activation - both should ultimately start
> a daemon (hopefully as the right user in the case of the former ;))
>
>>>> So, how could downstreams that need to support both systemd and
>>>> sysvinit (selectable at runtime) do so?
>>>
>>> Hopefully I've answered your question, but feel free to discuss further
>>> if you think there is still something that's not covered.
>>
>> Well, yes. But I did not want the answer to be: keep using autospawn
>> ;).
>
> :)
>
>> Because autospawn has its own class of problems (it can be
>> autostarted by a service running as a different user, leaving the user
>> without audio[1], or malformed configurations can thrash the
>> computer[2]), I would really like to disable it by default.
>
> Yeah, I have fought with it before. It's actually been quite a useful
> and highly visible indicator of wider environment leakage (e.g. leaving
> XDG_* set after su or sudo or pkexec) which means it got fixed. Without
> PA's autospawn getting all in your face, some of the other issues likely
> would have gone unnoticed!
>
> That said, I'm pretty sick of them now myself too, so yes socket
> activation will be much nicer  :D
>
> So, back to the point, the only thing that really differs between the
> builds when systemd support is built is the default value of autospawn
> for the client, so all you really need to deal with downstream is
> setting up /etc/pulse/client.conf correctly.
>
> If you wanted to go really far, you could also hack PA source to check
> for systemd as an init (just checking sd_booted() I guess) and make the
> default based on that - while it's not the same as using the user
> daemon, it's 99% accurate IMO. It would make the default value shown in
> the config file (but commented out) sometimes wrong, but that's mostly
> cosmetic.
>
> We could technically just do this upstream. I don't think I'd be against
> such a change if no-one else complains.

I had thought of that. I think this is a reasonable compromise:
business as usual for the no-systemd crowd, and improved support for
the rest.

I will try to cook something up along the lines of your suggestion (I
don't think you can assign a method call result to a const struct
field...). I'll let you know if I have something that works.

-- 

Saludos,
Felipe Sateler