It's non-obvious, though. Change something in /etc/systemd you can expect to have to tell systemd about it. Outside of that directory, there's no indicator you should do so.
"Long time" is also relative. I've been updating /etc/fstab directly for over 25 years.
> and for a good reason
Yeah... there's always a "good reason" with systemd, isn't there?
Still doesn't account for the lack of error message.
It's kind of funny how systemd breaks often when old farts (like us) tinker with something in a way we shouldnt.
Re:Troubleshooting Systemd with SystemTap
by michaelmrose on Thursday April 30, 2020 @08:35PM
(#23037950)
Why doesn't it reparse fstab before executing mount commands?
the mount command is not part of systemd
Re:Troubleshooting Systemd with SystemTap
by michaelmrose on Saturday May 02, 2020 @04:03PM
(#23054479)
mount the command DOES read /etc/fstab I believe the discussion was a systemd mount unit
/etc/fstab is parsed by systemd and converted int .mount unit files, so that they can be mounted when a) asked for it (auto/noauto) and b) as soon as possible.
think of the _netdev flag: it signals systemd that a mountpoint is network-based, and thus it will attempt to mount it only after the networking target (instead of waiting for it to timeout at boot time, fail , and possibly letting processes start reading and writing from/to an empty directory).
Running daemon-reload is generally system(d)-wide though: whenever systemd configuration is altered (think adding/removing/updating an unit file) you should let systemd know about that by running systemd daemon-reload (think of apachectl reload).