[systemd-devel] Stricter handling of failing mounts during boot under systemd - crap idea !

[Lennart Poettering]

On Mon, 29.06.15 19:17, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> > The systemd community only recommends what downstream consumers of it 
> > should do
> 
> No. systemd changed interpretation of well established configurations
> in incompatible way. There is no way to retain existing behavior. It is
> far from "recommends" - it is "my way or highway".

The old scheme worked by waiting for some weakly defined time until
all block devices appeared first, and then mount them into places and
proceed. But that's not how computers work these days, since devices
can show up at any time basically and busses like USB or iSCSI or
anything else that is basically not soldered-in ATA that you loaded
the kernel from have no strict rules by which time the devices have to
have shown up after you turned on the power.

The old logic was not reliable: if you had anything that was not the
simple ATA case, then you'd run into races, where the mount call would
not find the devices it needed because they hadn't finished probing
yet. And if you had the simple ATA case, then you'd have to wait much
longer for the boot than necessary due to the weakly and weirdly
defined settle time, tht was much longer than necessary.

So: the old mode was borked. It was racy, unsecure, and simply not
compatible with how hardware works. 

systemd is really about dependencies and starting/waiting for exactly
the events that we need to wait for. On one hand that means we don't
wait for longer than necessary, and on the other hand this means we
don't wait for shorter than necessary. The old pre-systemd solution was
in conflict with both of these goals.

And this has nothing to do with "my way or the highway", this is
really just about getting basic behaviour right, for something that is
conceptually at the core of what systemd is.

Also, we do offer the opt-in to something resembling the old behaviour
via "nofail", but you should use that only acknowledging that the
services will race against the mounts then, and might see parts of the
file system below it, might open files there only to see the directory
overmounted later on.

> The problem is that systemd community does not care to even explain
> the reasons for this change.

This is simply not the truth. This has come up many times before, and
I gave the very same explanation as above every single time.

> It simply ignores any complaints and bug
> reports. 

Wut? we ignore "any" complaints and bug reports? 

I spend more time on bugzilla these days than on anything else. Good
to know that you appreciate that. 

> Of course systemd community does not get to see much of them
> - most users who are pissed off by these changes are not those who
> would try to e-mail this list. So to systemd community it looks like
> everyone is happy except couple of old farts. 

Oh, wow, I figure you mean me by that? 

Thank you for your very constructive addition to the discussion.

Lennart

-- 
Lennart Poettering, Red Hat