On Thu, Dec 4, 2014 at 5:50 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Tue, 02.12.14 09:40, Michael Marineau (michael.marin...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
