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

[Lennart Poettering]

On Tue, 23.09.14 09:09, Jan Synacek (jsynacek at redhat.com) wrote:

> 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.

Well, the root dir doesn't have to be read-only. For example, when
systemd is invoked within a container environment the root dir is
usually already writable.

Lennart

-- 
Lennart Poettering, Red Hat