[systemd-devel] preset enables everything by default

[Michael Marineau]

On Thu, Dec 4, 2014 at 5:50 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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.

They aren't listed, that's why I'm asking about the default. :)

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

So when assembling a machine image that will be used to create a bunch
of pre-configured hosts the correct thing to do is 'echo >
machine-id', not 'rm machine-id'?

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

And I've added this to CoreOS too. The gist of my rambling email was
why is this not the default?

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