[systemd-devel] systemctl preset for user units (and how presets are applied after factory reset)

[Colin Guthrie]

Hi,

When implementing socket activation for PulseAudio, the question came up
of how to ship the enablement when running "make install".

In my first incarnation I simply shipped a
/usr/lib/systemd/user/socket.target.wants/pulseaudio.socket symlink. I
did this because I considered this a vendor choice (as opposed to an
administrator choice) and that's probably what I'd do downstream
(although I will add an additional condition in the unit so that it
doesn't run when the user has an "ALSA Sound Profile" (where "Sound
Profiles" are our downstream way of managing this choice for users), but
this is out of scope here).



However, this decision sparked some debate about whether we really
should add such a "hard" enablment during make install.

Perhaps the user .socket unit should just have an [Install] section and
it should be up to the packagers to call "systemctl --global enable" at
package install time.

This would mirror system services for the most part... with the
exception that system services should really be calling preset...


So that led me to ask myself: does systemctl preset support user units?
The man page doesn't make it clear that e.g. the --global switch applies
to preset as well as enable, but in testing it (happily) appears to
work! So I'm going to answer that question with a "yes, it does work!"



So, as preset works for user-units, I'm thinking that we should NOT ship
a /usr/lib/systemd/user/socket.target.wants/pulseaudio.socket symlink
and leave it to downstream packagers to call "systemctl preset --global
pulseaudio.socket" when the package is first installed. This will create
the /etc/systemd/user/socket.target.wants/pulseaudio.socket symlink for
us and all is well.

[As a side note, if this is the recommended approach, then we should
probably add appropriate RPM macros to macros.systemd for user unit
presets...]


There are, however, two questions still remain:

1. As we have two units, pulseaudio.socket and pulseaudio.service, and
as the desired behaviour is to enable only the socket but not the
service (i.e. by default rely on socket activation - don't waste
resources unless a client actually connects; this is a bit of an
assumption - perhaps this should be desirable?) should we:
  a) Recommend packagers only call "systemctl preset --global
pulseaudio.socket"
  b) Recommend packagers call "systemctl preset --global
pulseaudio.socket pulseaudio.service", but remove the [Install] section
from the .service
  c) Recommend packagers call "systemctl preset --global
pulseaudio.socket pulseaudio.service", but ship a preset file in
/usr/lib/systemd/user-preset/50-pulseaudio.preset that has "disable
pulseaudio.service" in it.

systemd.preset(5) suggests not to do c) but I think this could be an
example of an exception to that rule (to me this seems cleanest)?
Perhaps there are other socket+service pairs where this makes sense too
however, and this should be encapsulated in the preset logic more
generally? (i.e. the default logic is "if a .service unit is set to be
enabled, double check to see if it has a corresponding .socket unit
which will be enabled and if so, skip enabling the .service".



2. On factory reset, I do not see any calls to systemctl preset, for
either the system or user units. Am I missing something or is this
something which should be part of the factory reset logic (i.e. a unit
with ConditionNeedsUpdate=/etc to call systemctl preset - if so, it
would presumably also need to reload systemd if any work was done for
system units, but we can assume this is safely completed before any user
instances kick in).


Thoughts welcome :)

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/