Re: /etc/fstab obsolete?

On Mi, 28.08.19 09:33, Ulrich Windl (Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx) 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!

You need to issue "systemctl daemon-reload" when updating this file,
systemd only takes notice of changed configuration files when you
issue that.

This is documented widely, for example here:

https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

Moreover, well-meaning distributions would most likely include a
comment about this in /etc/fstab to make this discoverable easily by
the admin. On Fedora you'll find this comment at the top of the file
for example:

<snip>
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
</snipe>

systemd does not automatically reload configuration files when they
change since that is inherently racy: systemd reads a larger number of
unit files and other configuration files and simply by watching file
changes with inotify we cannot know when the right time is to reload
configuration: we might end up seeing some of the old
unit/configuration files and some of the new unit/configuration files,
as they are manipulated if we reload at the wrong time. For example,
consider the case where you rename a unit file: there is likely a
timeframe where enumerating all unit files might see just the old
name, and one where it would see just the new name. It might also
happen that enumeration sees the file both under the old and the new
name, or under neither (simply because file enumeration is a long
process). In all these cases we'd end up reading a borked
configuration, hence we just don't do that.

It is expected for the admin to issue "systemctl daemon-reload"
explicitly at the correct time, i.e. when a set of changes to
configuration and unit files is complete and before the next set of
changes is begun. Only the admin really knows when that is. (I mean,
the alternative would be if we'd have a transactional file system on
Linux, but we do not, and I don#t see that coming either.)

(Another example where things might go very wrong if we'd start
reading configuration files at the wrong time: consider RPM
removing/updating/installing a bunch of unit files in one go: if we'd
wake-up whenever even one file changes we'd very likely wake up at the
wrong time and see a file removed with its replacement not there yet,
or the opposite. So if we did that and you update a bunch of RPMs at
once you'd basically get the guarantee that you will hit this case.)

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!

So, there are changes between systemd and pre-systemd, non trivial
ones, even. They are documented though, and generally well
communicated. Yes, there's a learning curve, and yes you have to read
some docs if you have a non-trivial setup you want to convert to
systemd. But I am not sure why you unload this on our doorstep. There
are technical reasons for these choices, documented ones even. If you
convert a machine from pre-systemd systems to systemd, please
read the docs thoroughly, and understand the incompatibilities that
there are. We write these docs because we know how important this is,
not so that you then ignore all we did and blame us anyway. And no,
doing a live-update between major OS releases of production
infrastructure without reading the docs is a very very bad idea, but
not one we came up with, did we?

I mean, short of actually *being* sysvinit there's literally nothing
we could do to make you happy, can we?

Anyway, please vent your frustrations elsewhere, this is not helpful
nor new.

And: RTFM!

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Compliments to Lennart, for writing a civilized and clear reaction.

In the past, I had my share of frustration with systemd too. To little options or none for conditional execution, translating init files to service files etc. So, as an professional, I started to read manuals, which did not make me more happy, but gave me a better understanding. Now, I find writing service files much easier then init files, only debugging is still a challenge - for me.

The only real concern I have, is that it seems to me that systemd is ever more encroaching into the realm of the Linux kernel itself.

--- Frans.