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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Frantisek Sumsal GPG key ID: 0xFB738CE27B634E4B
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
