[systemd-devel] /etc/fstab obsolete?

[František Šumšal]

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.

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.

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.

> 
> 
> 
> 
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190828/ede794f3/attachment.sig>