[systemd-devel] Antw: Re: /etc/fstab obsolete?

[Ulrich Windl]

>>> František Šumšal <frantisek at sumsal.cz> schrieb am 28.08.2019 um 10:18 in
Nachricht <ebf218ec-3ee0-591c-4226-b90359f82bd6 at sumsal.cz>:
> On 8/28/19 9:33 AM, Ulrich Windl wrote:
>> Hi!
>> 
>> systemd in SLES 12 is causing endless frustration here:
>> 
>> Yesterday I was migrating some filesystems to a new device (multipath, 
> MD-RAID, LVM, filesystem, mountpoints, etc.), updating /etc/fstab and other

> files as needed.
>> After migration was successful, I also cleaned up the now obsolete
resources 
> (multipath, MD-RAID, filesystem, mountpoints, etc.)
>> Everything looked OK...
>> 
>> But some time later the application was stopped, as the new filesystems
were 
> unmounted by systemd (even though active processes were using it) WITHOUT 
> giving a reason for "Stopped target Local File Systems" in syslog. Instead 
> systemd tried to mount the filesystems that had been removed from
/etc/fstab!
>> 
>> It seems systemd does not like root to unmount a filesystem that is still 
> present in /etc/fstab.
>> 
>> So I tried to "start local filesystems" after realizing the problem this 
> morning. Then disaster (named "systemd") strikes back:
>> It tried to mount the old filesystems that do no longer exist (and are no 
> longer present in /etc/fstab), resulting in a "dependency failed", and in 
> turn it transitioned a fully running server from multi-user mode to
emergency 
> mode, shutting down all services, network, etc.
>> 
>> That is why I hate systemd!
>> 
>> I did a "daemon-reload" in the emergency shell, and then I was able to
start 
> the default target again.
> 
> It looks like you forgot to issue `systemctl daemon-reload` after updating 
> /etc/fstab, which is, actually, a documented incompatibility
> with SysV scripts:
> 
> Excerpt from 
> https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/: 
>> On SysV systems changes to init scripts or any other files that define the

> boot process (such as /etc/fstab) usually had an immediate effect on 
> everything started later. This is different on systemd-based systems where 
> init script information and other boot-time configuration files are only 
> reread when "systemctl daemon-reload" is issued. (Note that some commands, 
> notably "systemctl enable"/"systemctl disable" do this implicitly however.)

> This is by design, and a safety feature, since it ensures that
half-completed 
> changes are not read at the wrong time.

The last sentence is nonsense; maybe it's just to put this mis-feature in a
better light:
If nobody told systemd to act on obsolete information it once had extracted
from fstab, it shouldn't do that.
And if it thinks it must react on any manual mpount or unmount, it should
consider the current fstab first before doing bad things.

Despite of that if some mount or unmount fails, why not log an error, and keep
it that way? That would be much better than putting a running server into
emergency mode!


> 
> As you stated later, running `systemctl daemon-reload` later fixes the 
> issue, because that's what you're supposed
> to do after updating pretty much any configuration when it comes to
systemd.

Can't systemd simply discard mount information that is older than fstab, or
being derived from a different fstab? inotify?

I hope the answer is not "No, because generators are called very early in the
boot process".

> 
> Also, I'm still amazed how you expect people to help you with all the 
> "insults" on systemd's behalf - maybe try to refrain from
> doing them in the future, as the issue may not be in systemd. And even if it

> is, this attitude won't make it magically better.

Some design concepts in systemd are just insane, the fstab issue being a good
example for that.

So far the time systemd saves during boot or shutdown is in no reasonable
proportion to the many hours of extra work it caused for the administrator (me)
to get  a system up that systemd downed.

Regards,
Ulrich