On Mon, 2015-06-29 at 18:45 +0200, Lennart Poettering wrote: > On Mon, 29.06.15 19:17, Andrei Borzenkov (arvidj...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
