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. > 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
