I no longer have to learn a three-dimensional grid of init systems (init system, distro, distro release).
If this isn't a positive experience...
Systemd requires a small initial study effort in order to be understood.
If you're unwilling to do that kind of things (is: reading the fine manual), you might as well go buy a macbook.
After poking the internet:
After altering fstab one should either run systemctl
daemon-reload (this makes systemd to reparse /etc/fstab
and pick up the changes) or reboot[^1].
BTW, this is not the first one for me, but certainly one of the most frustrating ones, and not because of the behaviour: because of the lack of error messages on stderr or at least in syslog. The messages in ~~syslog~~ journald were casual.
[^1]: https://unix.stackexchange.com/questions/169909/systemd-keep...
/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).
Yeah... there's always a "good reason" with systemd, isn't there?
Still doesn't account for the lack of error message.
"Long time" is also relative. I've been updating /etc/fstab directly for over 25 years.