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