[systemd-devel] /etc/fstab obsolete?

[Frans de Boer]

On 28-08-19 14:41, Lennart Poettering wrote:
> On Mi, 28.08.19 09:33, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) 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 at lists.freedesktop.org
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190828/ddb424ce/attachment-0001.html>