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

[Tanu Kaskinen]

On Fri, 2014-10-24 at 11:00 +0100, Colin Guthrie wrote:
> Tanu Kaskinen wrote on 24/10/14 10:28:
> > On Mon, 2014-10-20 at 11:54 +0100, Colin Guthrie wrote:
> >> ---
> >>  configure.ac                                  | 11 +++++++++++
> >>  src/Makefile.am                               | 12 +++++++++++-
> >>  src/daemon/systemd/user/pulseaudio.service.in | 10 ++++++++++
> >>  src/daemon/systemd/user/pulseaudio.socket     | 10 ++++++++++
> >>  4 files changed, 42 insertions(+), 1 deletion(-)
> >>  create mode 100644 src/daemon/systemd/user/pulseaudio.service.in
> >>  create mode 100644 src/daemon/systemd/user/pulseaudio.socket
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index 3a249d0..6c9690f 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -1199,6 +1199,13 @@ AS_IF([test "x$HAVE_SYSTEMD" = "x1"],
> >>          HAVE_SYSTEMD_JOURNAL=1
> >>      ])
> >>  
> >> +AC_ARG_WITH([systemduserunitdir],
> >> +        AS_HELP_STRING([--with-systemduserunitdir=DIR], [Directory for systemd user service files]),
> > 
> > The convention in PA seems to be to use more dashes:
> > --with-systemd-user-unit-dir
> 
> This has been merged into a lot of other projects without the dashes
> (including alsa-utils) and it's also the name of the variable that us
> used in the pkg-config files shipped with systemd, so I'd really rather
> keep it consistent across projects/with systemd if you've not got a
> super strong feeling on this one?

No, I don't have a super strong feeling on this.

> >> --- /dev/null
> >> +++ b/src/daemon/systemd/user/pulseaudio.service.in
> >> @@ -0,0 +1,10 @@
> >> +[Unit]
> >> +Description=Sound Service
> >> +
> >> +[Service]
> >> +ExecStart=@PA_BINARY@
> >> +Restart=always
> >> +
> >> +[Install]
> >> +Also=pulseaudio.socket
> >> +WantedBy=default.target
> > 
> > Given that we have socket activation, what is the benefit of starting
> > PulseAudio unconditionally as part of default.target? We'll probably
> > patch the WantedBy line out in Tizen (we have a policy to not start
> > services on demand, so we have so far relied on autospawning alone to
> > start PulseAudio).
> 
> This is ultimately user choice. They *may* want to enable pulseaudio
> anyway so that it's preloaded and ready before the first client tries to
> connect. Practically speaking [modulo a discussion that is ongoing on
> systemd ML regarding when pam actually returns from a login session -
> either when the users basic.target or default.target is reached], this
> is arguably unlikely (in desktops mixers and settings-daemons connect
> very early on in the session launch and would thus trigger it), but I
> don't see any reason to forbid it - most users would not actually call:
> "systemctl --user enable pulseaudio.service" manually anyway. I don't
> see why you'd need patch it out as [Install] sections don't do anything
> if you don't actually enable it via the above command, so in Tizen, I'd
> just assume you wouldn't do that and then it wouldn't matter at all.

If we remove WantedBy, the user is still free to add the the
default.target.wants link by him/herself, so saying that this would
"forbid" something sounds strange.

As for why we'd patch it out in Tizen: I was thinking that we'd probably
call systemctl --global enable when installing the package for the first
time. My belief (not backed by much evidence) has been that it's common
for packages to do that, and it certainly makes sense to me to do so
(you want to enable the new service by default, but allow users to
disable it if they so choose).

> An example of where this might be desirable is for a user with a very
> complex TCP based setup. He may want to set that up in default.pa, but
> not bother configuring the pulseaudio.socket to match (and as I've not
> written the TCP socket activation bits yet ;)).

Ok, making it more likely that PulseAudio is running for TCP clients is
a valid argument, but not very strong. If you want to enable remote
access, running in system mode probably makes more sense, because then
the availability won't be tied to a particular user being logged in
locally (and no, user lingering isn't a very good solution, since it
breaks the device permission management).

> This user may want to
> use systemd's "User Lingering" feature to start up PA when his machine
> boots so he can use it while not logged in (see the Wiki page I wrote
> for more on this). In this scenario, they'll want to enable pulseaudio
> manually.

As a pre-requisite for making the user lingering useful, the wiki page
recommends adding the user to the "audio" group, which is really ugly.
I'm not saying that you should remove that from the wiki page, but I
wouldn't say that doing that is recommended like the wiki page says now.

> This also mirrors configurations I've seen in some other systemd units
> (e.g. cups), where the service can be socket, path or bus-activated but
> it can also be statically enabled should the system configurator/user so
> desire.
> 
> Hope that's a good justification :)

Well, I'm not really convinced :/ There are no huge downsides to having
WantedBy=default.target, though, so I don't feel very strongly about
this.

-- 
Tanu