[pulseaudio-discuss] [PATCH] launch: Add systemd units for launching pulseaudio user instances
Colin Guthrie
gmane at colin.guthr.ie
Fri Oct 24 03:00:52 PDT 2014
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?
>> --- /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.
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 ;)). 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.
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 :)
That said, the Also= line should be killed as the socket is enabled
statically now (it wasn't in an earlier version of the units), and thus
no [Install] rules should be followed for it when enabling/disabling the
service (which is all Also= does).
I'll fix that bit up.
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/
More information about the pulseaudio-discuss
mailing list