[systemd-devel] [RFC] Preset Files

Kok, Auke-jan H auke-jan.h.kok at intel.com
Tue Jul 5 20:48:54 PDT 2011


On Tue, Jul 5, 2011 at 3:42 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Wed, 06.07.11 00:26, Kay Sievers (kay.sievers at vrfy.org) wrote:
>
>> >> If "systemctl preset" is passed with unit names, those units would
>> >> be enable/disabled as listed in the preset file. If no argument is
>> >> passed all units would be reset to the preset defaults. (another
>> >> long-sought feature...)
>>
>> We will require an argument. There will no 'change all services'
>> logic.
>
> Uh?
>
> Actually, I do want a way how people can reset all service enable states
> to what the vendor intended. And that should be "systemctl preset"
> without arguments I believe.

I've been monitoring this discussion with some reservation:

Restoring the initial vendor/distro state should be as easy as
restoring /etc/systemd/system. I don't see why presets will fix this,
it's much more likely to become yet another update-alternatives where
unintended consequences or wrong use.

I can already see people asking me for "multiple different presets" -
in MeeGo, unfortunately people think in little boxes and they assume
that inside their box they should be able to do anything as it won't
affect other classes of use. This means that my life as
"systemd-overseer" will become pretty hard with presets as now I'll
have people ""sneaking"" in services settings in some extra package,
instead of the systemd hookups in the package installing the service.

Also, I'm really keen on keeping distro-provided symlinks and services
in /lib/systemd/system, and SA local changes in /etc/, so I will not
want to allow MeeGo rpm's using the macro's previously posted, as they
call `systemctl enable` instead, which counters that, and that leads
to an unclear situation, and that will just result in people not
understanding things when they add new packages..., and then it gets
out of hand fast. Not something that I want to have in the next few
months before our 1.3 release.

For reference, in MeeGo we ship and enable service files most of the
time. Services that get installed by default are almost always enabled
by default too (with symlinks under /lib/systemd/system). Services
that do not get installed by default almost always have their service
files disabled by default, a few exceptions here and there. But then
again, most services in MeeGo do not require any SA configuration,
since we don't package things like samba servers, httpd, mysql etc.

So, bottom line for me is that aiding packaging (with macro's, if done
correctly) is good, but presets just sound like a band aid :)

Auke


More information about the systemd-devel mailing list