On Tue, 13 Aug 2019 at 11:50:27 +0200, Marc Haber wrote: > On Thu, 8 Aug 2019 22:44:19 +0100, Simon McVittie <s...@debian.org> > wrote: > >Making /etc/machine-id a 0-byte file is considered to be the canonical > >way to clear it, rather than actually deleting it, because if systemd is > >running on a completely read-only root filesystem, it has code to create > >a machine ID on a tmpfs and bind-mount it over the top of the empty file. > > And what will systemd do when it encounters a zero-sized > /etc/machine-id on a writable filesystem?
Replace it with a new machine ID, the same as if it didn't exist at all: After the machine ID is established, systemd(1) will attempt to save it to /etc/machine-id. If this fails, it will attempt to bind-mount a temporary file over /etc/machine-id. It is an error if the file system is read-only and does not contain a (possibly empty) /etc/machine-id file. — machine-id(5) (systemd cannot create a mount point that doesn't exist yet on a read-only file system, which is why a zero-byte file is preferred.) > >If you are doing cloning, stateless systems or similar activities, > >and you know you will have a valid /etc/machine-id (you either use > >systemd or have taken other steps to have one), then you can make > >/var/lib/dbus/machine-id a symlink to /etc/machine-id (dbus comes with a > >systemd-tmpfiles file to do this). This is not done by default in Debian, > >or by `dbus-uuidgen --ensure`, for historical reasons > > Interesting, I see this on a number of my test systems without having > been active in this regard myself. If you use systemd as init, install dbus, delete or empty /etc/machine-id, delete /var/lib/dbus/machine-id and reboot, then systemd will recreate /etc/machine-id very early in the boot process. Less early but still early in the boot process (before units with DefaultDependencies=yes, analogous to rcS in sysvinit), systemd-tmpfiles will make /var/lib/dbus/machine-id a symlink as directed by /usr/lib/tmpfiles.d/dbus.conf. By the time ordinary system services start, it is already a symlink. Might this be what happened on your test systems? I'm fairly sure that dbus-uuidgen (which is run in dbus.postinst, and from /etc/init.d/dbus on non-systemd systems) always makes /var/lib/dbus/machine-id a regular file rather than a symlink, but if you already had dbus installed before you reset the machine ID, and you did not subsequently boot with a non-systemd init, then dbus-uuidgen wouldn't have been run. If /var/lib/dbus/machine-id is already a symlink to a file with contents in the right format, dbus-uuidgen won't replace it. > >Maybe /etc/machine-id should be part of the "API" of a Debian system in > >general (systemd or not)? > > please elaborate on that. There are some properties that we guarantee every Debian system will have, even though they cannot be guaranteed on every GNU or Linux system. For example, Policy guarantees that /var/run is always a symlink to /run on Debian systems (even though they are distinct directories on e.g. Slackware[1], and as a result upstream projects like dbus can't rely on /var/run being equivalent to /run). Similarly, we guarantee that all Debian systems will have the base-passwd users and groups, with their canonical numeric values. Some of those properties either originated in systemd and were adopted in Debian for even non-systemd systems (for example /usr/lib/os-release in base-files, which originated in systemd as a replacement for lsb_release and distro-specific facilities like /etc/debian_version), or originated in Debian or some other distro and have been adopted by systemd as one of its "API" guarantees on all distros that use it (for example systemd picked up Debian's /etc/hostname, /etc/timezone and /etc/sysctl.d). In both cases this is done on the basis that regardless of origin, they are good ideas that should be spread further, and giving application and library maintainers more "API" guarantees from the OS makes their jobs easier. What I'm suggesting is that maybe a systemd-style /etc/machine-id should be one of those properties that we guarantee, instead of relying on dbus (which is an IPC system that has very little to do with uniquely identifying a machine) to provide the closest thing that is guaranteed on non-systemd-booted machines. Because systemd does not delete /etc/machine-id even when purged (that would be counterproductive for its intended purpose, and would break stored state that refers to it), it is present on all systems that either boot with systemd or have switched from systemd to sysvinit. The only Debian systems that will not already have /etc/machine-id are those that were installed before systemd became the default (wheezy or older) or as a minimal debootstrap with no init system at all (jessie or newer), may have subsequently been upgraded to newer suites, but have never run systemd.postinst or booted with systemd. smcv [1] I think this is an unwise design decision, and with my dbus upstream hat on I tried to get it changed, but I was not successful.