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

[Colin Guthrie]

Tanu Kaskinen wrote on 24/10/14 11:55:
>>> 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.

OK, I'll keep it as is unless anyone else raises any further objection.

>>>> +[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.

Point taken. It doesn't forbid it, it just makes it more complex.

> 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).

I don't think systemctl --global enable would apply to user units does
it? I thought it was only for system units.

Also, if it did apply to user units it would create it in
/etc/systemd/user/default.target.wants/ not in the individual user's
~/.config/systemd/user/default.target.wants/ folder. So any individual
user wanting to disable it would still have to mask it (in
~/.config/...) if they didn't have admin rights to do so globally for
all users by removing the symlink in /etc/...


As a side note, I really don't think "systemctl --global enable" is wise
regardless. From a distribution/packager perspective, I would strongly
discourage this. If anything I'd say that that "systemctl preset
foo.service bar.service ..." is the wisest choice (where the services
(or other units) are only the ones included in the package being installed).

>> 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).

I kinda disagree as I would personally rather run my user PA for this
via lingering and add my user to the audio group, but that's maybe more
my personal taste than anything else?

Does anyone else have much of an opinion on this? When I discussed the
lingering solution with Arun he seemed to like it but perhaps on
reflection he'll disagree now :) System mode might still be the best
option for such people although I do like the relative simplicity of
this one seeing as we've always talked about system mode not being
recommended etc.

>> 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.

OK, noted - I can reword it appropriately until you're happy in due
course :)

>> 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.

Yeah, it's not that big a deal either way :)

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/