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

Colin Guthrie gmane at colin.guthr.ie
Tue Nov 4 10:39:23 PST 2014


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.

Something like below:

diff --git a/man/pulse-client.conf.5.xml.in b/man/pulse-client.conf.5.xml.in
index 7025df7..b5794f1 100644
--- a/man/pulse-client.conf.5.xml.in
+++ b/man/pulse-client.conf.5.xml.in
@@ -69,7 +69,9 @@ USA.

     <option>
       <p><opt>autospawn=</opt> Autospawn a PulseAudio daemon when
-      needed. Takes a boolean value, defaults to
<opt>@PA_DEFAULT_AUTOSPAWN@</opt>.</p>
+      needed. Takes a boolean value, defaults to <opt>no</opt> when
+      pulseaudio is complied with systemd daemon support and systemd
+      is detected as PID1 and to <opt>yes</opt> otherwise.</p>
     </option>

     <option>
diff --git a/src/pulse/client-conf.c b/src/pulse/client-conf.c
index 80ddae0..a5c1bd5 100644
--- a/src/pulse/client-conf.c
+++ b/src/pulse/client-conf.c
@@ -44,6 +44,10 @@
 #include <pulse/client-conf-x11.h>
 #endif

+#ifdef HAVE_SYSTEMD_DAEMON
+#include <systemd/sd-daemon.h>
+#endif
+
 #define DEFAULT_CLIENT_CONFIG_FILE PA_DEFAULT_CONFIG_DIR PA_PATH_SEP
"client.conf"
 #define DEFAULT_CLIENT_CONFIG_FILE_USER "client.conf"

@@ -66,7 +70,7 @@ static const pa_client_conf default_conf = {
     .cookie_file_from_application = NULL,
     .cookie_file_from_client_conf = NULL,
 #ifdef HAVE_SYSTEMD_DAEMON
-    .autospawn = false,
+    .autospawn = !sd_booted(),
 #else
     .autospawn = true,
 #endif




-- 

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