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

Colin Guthrie gmane at colin.guthr.ie
Mon Nov 3 08:30:08 PST 2014


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.

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.

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.

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

Cheers!


Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/


More information about the pulseaudio-discuss mailing list