[systemd-devel] preset enables everything by default

[Lennart Poettering]

On Tue, 02.12.14 09:40, Michael Marineau (michael.marineau at coreos.com) wrote:

> I didn't catch this behavior when it was first introduced since
> originally it was much harder to trigger systemd's "empty /etc" logic
> but now that it only requires /etc/machine-id to be missing it is
> quite easy, booting a new instance from an image for example. By
> default applying presets enables everything unless there is a preset
> config that defines otherwise. I found this to be rather surprising,
> booting a fresh machine reported all sorts of failures by trying to
> start oodles of unconfigured services. 

Those services should not be listed as "enable" in the preset file if
they fail to start unless explicitly configured.

> Also the options are only "enable" and "disable" so the existing
> pattern of pre-preconfiguring a reference host and then creating an
> image (EC2 AMIs for example) won't work very well since the preset
> defaults will clobber what the user enabled/disabled. (assuming the
> user properly clears machine-id before creating the image which may
> be rare, in all likelihood many people just get away with having
> non-unique machine ids)

We use the machine-id file as check whether /etc is populated or
not. If people pre-populate /etc, and don't wan't the full
"first-boot" logic of systemd to take action, then they should also
add machine-id file there (they can even just touch it if they want,
which will disable the first-boot logic, but still initialize the file
either directly if writable or overmounted if not).

> This behavior is probably ok in the case of interactively using
> systemctl preset and preset-all when it is known that the user
> explicitly asked the system to do something and can see what it did.
> In the case of the system booting I would expect "do nothing" to be
> the default when no preset file explicitly sates otherwise.

Then ship a "disable *" preset file in /sr. In this case, nothing will
be enabled by default. THis is what we do on Fedora.

> Is there a particular reason for the existing behavior? Would
> switching the default to disable be reasonable or should the automatic
> at boot mode gain a third "do nothing" option? Not sure where the
> safest and least-surprising behavior lies while continuing to provide
> this preset functionality.
> 
> Personally I've always found the enable/disable terminology to be
> incredibly misleading to begin with since it only refers to
> configuration in /etc and units can be equally activated in /usr. If
> disable and mask were equivalent then the distro's "presets" would
> just be whatever is in /usr and there won't be a need for this extra
> preset mechanism to initialize /etc.

We have the "static" state for units that are statically on via /usr,
and hence aren't subject to "systemctl enable" and "systemctl
disable".

Lennart

-- 
Lennart Poettering, Red Hat