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

Lennart Poettering lennart at poettering.net
Thu Aug 29 14:13:17 UTC 2019


On Do, 29.08.19 08:19, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) wrote:

> > <snip>
> > # After editing this file, run 'systemctl daemon‑reload' to update systemd
> > # units generated from this file.
> > </snipe>
> >
>
> Unfortunately it's only half of the truth: Even if you do not modify
> /etc/fstab, but do manual mounts or unmounts, systemd will override your
> actions whenever it feels like it.
>
> So the racy burden is now for root: You'll have to manipulate mounts and
> /etc/fstab synchronously, faster than systemd can react.
> I very much prefer what we had before: Commands are executed when you tell
> them to be executed.

systemd reacts automatically to state changes of the kernel. It does
not react automatically to configuration file changes. i.e. it watches
/proc/self/mountinfo for changes, it does not watch /etc/fstab. If you
make changes to the list of mounts currently established systemd will
follow that. If you make changes to the configuration file you need to
issue "systemctl daemon-reload".

> > 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.
>
> Maybe implement "transactions".

We kinda did. It's called "systemctl daemon-reload". Run that when you
are done with your config changes. These transactions only cover
configuration file changes. For runtime state changes we follow things
instantly and continously.

> I really don't understand what "unload this on our doorstep" means: Bring a
> common problem to your attention, while you consider any problems to be the
> user's fault?

Not quite. Sure there are bugs in systemd. It's software after
all. Every software has bugs. And we try to fix them as they are
reported, every day. It's our job if you so will, besides some other
stuff. If you find a bug, report it. Ideally to your distro first,
they will propagate it to us. If you are sure it's an issue in current
upstream systemd, report it to us directly, be civil while doing that,
file a good bug report, have a technical discussion with us.

However, you are coming to this mailing list, in search for free
support, and just dump insults and hate mails onto our doorstep, all
the time. It's just massively annoying. Can't you understand that? And
yet, we still help you if you have a technical question we can
actually help you with — which you do every now and then.

I am sorry, but you appear to believe you are entitled to free,
unlimited support from us, and you request it in a tone that's just
awful, and still expect us to help you as nice as we can.

Anyway, please work on your attitude, it's awful,

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list