[systemd-devel] Incorrect logic when /etc/machine-id is missing

[Jan Synacek]

Simon McVittie <simon.mcvittie at collabora.co.uk> writes:
> On 22/09/14 10:27, Jan Synacek wrote:
>> If /etc/machine-id is missing on the system, the first open() call
>> should probably handle that case. That's actually not true (at least on
>> my system), because the underlying filesystem is read-only at that
>> time.
>
> *What* is not true on your system?
>
> Are you saying that it is not true that /etc/machine-id is missing?
> (From context, probably not.)
>
> Are you saying that the first open() call doesn't handle ENOENT? (It
> "handles" it by trying the second open() call, in the hope that that
> might work better, because maybe the first one failed with EPERM; trying
> the second one on ENOENT is useless, but harmless.)

Sorry for not being clear.

What I wanted to say was that the first open() call with O_CREAT flag
obviously fails, because the root filesystem is by default mounted
read-only first and remounted read-write later. I'm testing on Fedora
rawhide, which I forgot to mention too.

If, for some reason, /etc/machine-id is missing, the logic simply
doesn't work. I believe systemd shouldn't fail to boot just because it
couldn't write or open the id file. I'm not sure how to solve this
problem, though.

>> Now I was determined to fix this bug, however I'm left clueless as to
>> how this is actually supposed to work. Is the entire logic in this piece
>> of code wrong, or am I missing something? How is the
>> (re)generating/mounting of machine-id supposed to work?
>
> Installation of systemd is meant to create and populate /etc/machine-id
> (in the dpkg postinst, RPM %post, or whatever is the equivalent on your
> distribution).
>
> If that doesn't happen, systemd does the best it can to rectify the
> situation. Re-creating it would work, if your initramfs happened to have
> mounted the root filesystem read/write.
>
> If you're deleting /etc/machine-id in order to wipe a machine's identity
> when cloning the filesystem, then, yes, the "generate a temporary
> machine ID and mount it over the top" logic is not going to work. In
> Debian's live-build tool, I contributed a patch[1] to change the logic
> from "delete /etc/machine-id" to "truncate /etc/machine-id to 0 bytes",
> which works better. That might help your situation?

It doesn't help my situation, because I simply remove the file by hand
and then try to boot the system. However, it brings a question if
"missing /etc/machine-id *and* the machine is still booting" should even
be a valid use case. I still believe it should be and it should be
handled by systemd, not by external scripts/processes.

>     S
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745840

-- 
Jan Synacek
Software Engineer, Red Hat