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

Felipe Sateler fsateler at debian.org
Mon Nov 3 04:55:37 PST 2014


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

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.

4 is clearly undesirable. 1 would be a shame since systemd service
management is nice. I'm not sure how to evaluate 2 and 3. My gut tells
me 2 is better, but I don't know if either could cause problems.

So, how could downstreams that need to support both systemd and
sysvinit (selectable at runtime) do so?

-- 

Saludos,
Felipe Sateler


More information about the pulseaudio-discuss mailing list