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

[Felipe Sateler]

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.

>
> 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.

>
> As noted in the commit message there, the first call to pactl should
> autospawn PA if autospawn is enabled and if not then the script will
> fail. Either way, the net result should be the same provided you have
> autospawn enabled (which was, and remains, the default when compiled
> without systemd-daemon support).
>
> I think the only case where this is now different is if autospawn was
> disabled, but you still wanted to use PA. The use case for that is very
> corner case - typically it would be PA developers only (I used this
> before for example, but now there are much easier semantics for stopping
> and starting PA via the systemctl --user commands that can work at
> runtime and save faffing around with config files etc. which is nice :))
>
>> So, how could we accomodate non-systemd users when this patch set
>> enabled? I see the following options:
>>
>> 1. Do not enable the systemd user units (we might need this anyway
>> until dbus properly supports a login bus in debian, but for the
>> purposes of this discussion lets assume this problem has been solved).
>> 2. Revert the --start patch so that non-systemd users get pa started
>> on login. Or maybe guard the --start with a check for /run/systemd.
>> 3. Revert this patch.
>> 4. Do not accomodate non-systemd users.
>
> 5. Build it with --disable-systemd-daemon and just use regular PA
> autospawning as before. No need to worry about the missing "pulseaudio
> --start" in the start-pulseaudio-x11 script as this was previously
> patched out in Ubuntu and no-one seemed to mind there.

That would be option 1, actually.

>
>> 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.


[1] In debian this problem was caused once by speech-dispatcher, which
locked the audio device. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521675
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752762

-- 

Saludos,
Felipe Sateler