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

[Colin Guthrie]

Zbigniew Jędrzejewski-Szmek wrote on 27/10/14 13:52:
>> [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...]
> Good point.

I usually get one or two a year ;)

>> 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.
> 
> Neither of those. Distribution packaging should set the default
> policy, which in case of Fedora would be 'disable *', and
> the package specific policy, containing just 'enable pulseaudio.socket'
> assuming that only socket activiation is desired.

So: d) Recommend packagers call "systemctl preset --global
pulseaudio.socket pulseaudio.service" and ship separately the global
distro-wide preferences in another package?

> This way, full flexibility is retained, and distributions like
> Fedora that don't activate by default on package installation, and
> the ones like Debian that sometimes do, attain desired behaviour
> by simply chaning one or two lines in the presets files.

My main point was not really about the "enable by default or not" type
policy of presets, but rather what happens when you have socket+service
combos.

If your distro policy is to "enable by default", then is there a better
way to handle the case where you only want to enable sockets for the
services, but not the services themselves.

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

Basically, is the above something to cater for at a higher level in the
distro policy or not?


>> 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).
> I seems this should be done. I thought that factory-reset already does
> that...

Perhaps it does. I didn't see any obvious units when searching for
ConditionNeedsUpdate in the systemd git tree, but perhaps this is
achieved in a different way? I didn't search too much more than that so
could easily have missed it.

Col

-- 

Colin Guthrie
  http://colin.guthr.ie/