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

[Tanu Kaskinen]

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

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

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

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

If you're on a single-user system, then there's not much of a difference
between a system instance or an always-on user instance. On a multi-user
system things are different.

-- 
Tanu