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

[jon]

On Mon, 2015-06-29 at 18:45 +0200, Lennart Poettering wrote:
> 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.

Thank you, good explanation, I understand.

Still leaves me with real world problems from the change though.

Reversing the logic by adding a "mustexist" fstab option and keeping the
default behaviour would fix it.

Bringing up networking/sshd in parallel to the admin shell would also
mitigate my issue....

I can see that both proposed solutions have issues, but I suspect I am
not the only one who will not be pleased about this behaviour change.

Changes seem to made with a bias towards desktops or larger data
centres, but what about the people using discarded PCs and maintaining
small servers, lots of these floating around smaller organisations. 

Thanks,
Jon