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
<[email protected]> 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?
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
