This one caught me off guard while working on bumping from systemd 215 to 217 in CoreOS so I thought I would pass along a warning. There is now a 'preset' mechanism that allows the system to define whether to enable services when initializing an empty /etc. For any service that is not explicitly defined in a preset file the default is enable. Also, /etc is considered 'empty' if /etc/machine-id is missing when systemd first starts. Enabling every installed service is about the last response I would have expected to /etc/machine-id missing. The fix is: echo 'disable *' > /usr/lib/systemd/system-preset/99-default.preset The 90-systemd.preset file should probably also be removed since it enables a few services that the ebuild normally leaves disabled. http://www.freedesktop.org/software/systemd/man/systemd.preset.html Cheers, Mike
If you want the defaults changed, why not talk to upstream about it? Unless the user is doing something weird, a normal Gentoo system already has /etc/machine-id by the time systemd starts on boot, so this doesn't really affect us.
Off the top of my head I think the only time /etc/machine-id would normally need to be cleared is when creating a filesystem image that will be used to create new hosts or containers, that way the new hosts properly get new IDs on boot. But admittedly that is probably not common, most people can get away with non-unique machne ids. From the documentation it seems the expectation is to leave it to the distro to set defaults for everything but I will inquire upstream as to why the default is to enable. I suspect the reason is because the same code is also plumbed into systemctl preset/preset-all commands and when interactively using systemctl a default of "turn on" is less surprising. I will dig more and inquire upstream to see what the exact logic was. If you don't mind the existing behavior feel free to close this bug, I just wanted to pass along the note. :)
(In reply to mike@marineau.org from comment #2) > Off the top of my head I think the only time /etc/machine-id would normally > need to be cleared is when creating a filesystem image that will be used to > create new hosts or containers, that way the new hosts properly get new IDs > on boot. But admittedly that is probably not common, most people can get > away with non-unique machne ids. On Gentoo, /etc/machine-id is usually generated by pkg_postinst in the sys-apps/dbus ebuild. Our "stage3" tarballs do not contain sys-apps/dbus, so by happy coincidence they do not contain /etc/machine-id either. If/when we start shipping stage tarballs with systemd, we will need to add a step to remove /etc/machine-id, and inform the user to generate before booting.
(In reply to Mike Gilbert from comment #3) > (In reply to mike@marineau.org from comment #2) > > Off the top of my head I think the only time /etc/machine-id would normally > > need to be cleared is when creating a filesystem image that will be used to > > create new hosts or containers, that way the new hosts properly get new IDs > > on boot. But admittedly that is probably not common, most people can get > > away with non-unique machne ids. > > On Gentoo, /etc/machine-id is usually generated by pkg_postinst in the > sys-apps/dbus ebuild. > > Our "stage3" tarballs do not contain sys-apps/dbus, so by happy coincidence > they do not contain /etc/machine-id either. > > If/when we start shipping stage tarballs with systemd, we will need to add a > step to remove /etc/machine-id, and inform the user to generate before > booting. In the current state of things I was thinking of users creating AWS AMIs and similar when there isn't a good opportunity to add a unique ID between creating the image and booting a new machine based on that image. Systemd will properly initialize /etc/machine-id at boot time if it is blank (a bind mount is used if /etc is read-only) or doesn't exist (only works if /etc/ is read-write already).
Looks like this is wontfix then, right? :)
Yeah, I meant to close this a while ago. A global default of "disable" can cause just as many surprises as a global default of "enable" so there isn't an easy win.
