[pulseaudio-discuss] systemd socket activation support

[Colin Guthrie]

Tanu Kaskinen wrote on 19/10/14 18:10:
> On Sat, 2014-10-18 at 20:43 +0200, Colin Guthrie wrote:
>> Hi,
>>
>> So while at linux plumbers attending the systemd hackfest, I thought a good
>> use of the hacking time I had available would be to allow PulseAudio to be
>> activated via systemd's socket activation system.
> 
> Great, thanks for the patches!
> 
>> The changes needed are actually quite minimal, and by doing this we can
>> disable quite a lot of code in PulseAudio related to autospawning (which
>> does still seem to cause some problems for some users) and we also get a few
>> handy side effects too.
>>
>> It becomes much easier, as a developer, to stop the system PulseAudio and run
>> your own test instance i.e. you do not have to disable autospawning before
>> killing the system PA - you just run:
>>
>> systemctl --user stop pulseaudio.socket pulseaudio.service
>>
>> and then run your test version.
>>
>> A second advantage is that there is a relatively simple and documented way to
>> run e.g. mpd as a normal user before you login via the systemd user lingering
>> feature.
>>
>> I've written a few docs about all this here:
>> http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Software/PulseAudio/Documentation/User/Running/
> 
> It seems to be buried rather deep in the hierarchy ;)

Yeah that was a mistake :s

I did link to it from the main User page too
(http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/)

I did wonder a bit tho', as the main Documentation link in the menu when
you go to the Homepage
(http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/) takes
you to here:
http://www.freedesktop.org/wiki/Software/PulseAudio/Software/PulseAudio/Documentation/
which is wrong...

I clicked through on Documentation/User link there, then added my link
there, but it seems my edit is gone and the page no longer shoes the
link... (well it is there if you click edit but it seems the frontend
cache mustn't have been purged or something :s

I coped one of the other link formats then edited that... all very
weird. I'll clone it from git soon and try and tidy it up a bit and fix
some of the links.


> (I know, it's
> impossible to use the web UI to create pages where you want. I've
> learned to use git directly when I need to create a new wiki page.)

Yeah, seems like the best plan. Not sure about the frontend cache
tho'... odd.

> We support non-systemd systems too, so I think the page should be named
> something else than just general "Running", given that the contents are
> only about systemd. Or alternatively add similar documentation for
> non-systemd systems too.

I think the latter might be a good plan. I can do that if you think
that's the best of the two options.

> Also, I don't think "the preferred method of
> launching and running PulseAudio is via systemd" is an accurate
> statement. I'm sure it's your preferred method, but you can't generalize
> that to everyone :)

:) Yeah I'm probably biased. That said, the patch in it's current state
will automatically enable this due to AC_ARG_ENABLE() if the devel libs
are found. If we keep it working that way, then I'd argue it does become
the "preferred way", but happy to change it to default off if you think
that's the better option (and it might very well be for v6 if it goes in
in time)?

> Patch 6 is missing. Any idea where it went?

No idea... the joys of email... I've resent it. Hopefully it comes
through now. It should be a reply to patch 5.

[PATCH] launch: Add systemd units for launching pulseaudio user instances


It's pretty simple (although some of the command line arguments from the
other patch implementing this might be wise (I didn't really give it
much thought).


> I didn't really review the code, but I was very interested in how you
> solved the problem of figuring out how to map the socket activation fd
> to a given module-protocol-native-unix instance, so I took a quick look
> on that. Looks like a very nice solution.

Yeah, I'll be honest, I did actually do something similar to the other
patch first by having a kind of "adopt" method, but after fiddling
around a bit, I moved it more inline.

The beneift of this approach is that you can have multiple
"ListenStream=nnn" lines in the systemd unit, provided you have a
corresponding "load-module module-protocol-native-unix socket=nnn" line
in PA. When socket= is missing it defaults to
$XDG_RUNTIME_DIR/pulse/native which is what is currently specified in
the user unit (%t == $XDG_RUNTIME_DIR).

I didn't do the TCP bits, but I suspect the same approach can be used
there (rather than the _adopt methods) to get much the same results.

I can look to do that if you think this approach is more sensible overall?

I've just pushed this approach to start PA in Mageia as some users are
still complaining about login delays in KDE. I don't *think* it's
directly related to PA personally, but with Rex's (and your followup)
patches to get rid of one race in the start-pulseaudio-kde vs
start-pulseaudio-x11 stuff, but theoretically a PA client could trigger
PAs own native autospawn before the start-* script is run and could also
cause another race (should be non-fatal and also shouldn't really delay
things much, but... you know "should"). The benefit of using systemd is
that this race is completely avoided which is nice (and one reason why I
thing it should be the "preferred way" to start PA :))

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/