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

[Colin Guthrie]

Tanu Kaskinen wrote on 24/10/14 13:36:
> On Fri, 2014-10-24 at 12:53 +0100, Colin Guthrie wrote:
>> Tanu Kaskinen wrote on 24/10/14 11:55:
>>>>>> +[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.
> 
> From the man page: "--global: When used with enable and disable, operate
> on the global user configuration directory, thus enabling or disabling a
> unit file globally for all future logins of all users."

Oh right, sorry I was misunderstanding here. Yeah, that seems sensible.

>> 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/...
> 
> Yes, I realized this myself too soon after sending my email that the
> command will anyway write the .wants symlink somewhere where the users
> can't touch it, so it's not really any different from us installing the
> symlink (except that if we install the symlink under /var, then even the
> administrator can't override it with systemctl disable). Is it really so
> that systemd doesn't allow users to disable services that have been
> enabled at system level (except by using masking)? That sounds like a
> bug.

OK, you've convinced me!

I'll remove that rule and just leave it to the packagers downstream (and
add it as such to the wiki).

I'll still be taking the same approach downstream however, but that's
not a major issue.

>> 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).
> 
> The reason why I think (or thought) that it's common for packages to to
> use "systemctl enable" is that I read instructions for doing that on
> some distribution's wiki page about packaging. I think it was this page:
> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
> 
> I didn't read carefully enough to notice that starting from Fedora 18,
> presets are indeed the preferred method if units need to be
> automatically enabled when installed. I'm not familiar with presets, so
> I'll need to study that topic more.

I'm not actually sure how presets and --user work... i'll have to study
that more too :D


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/