I agree, but documentation doesn't seem to have high priority in debian, it's a cultural issue. For example, in OpenBSD a developer never changes anything without also making sure that the documentation everywhere is up to date. It's become part of the mindset.
<rant>Yesterday I tried to learn about how LXC is integrated in debian, at least the debian wiki article warned me that the page might be outdated if I tried it on the brand new "stretch" distro! And "man crypttab" explicitly says that it doesn't document what's actually used, to read about that one has to go online.</rant> On Wed, Jun 24, 2020 at 3:51 PM David Wright <deb...@lionunicorn.co.uk> wrote: > > On Wed 24 Jun 2020 at 09:32:53 (+0200), Anders Andersson wrote: > > On Wed, Jun 24, 2020 at 1:17 AM David <bouncingc...@gmail.com> wrote: > > > I just noticed a new bug report [1]: > > > """ > > > Dear Installer Team, > > > > > > Please consider adding words informing users they should run > > > "systemctl daemon-reload" after changing /etc/fstab. > > > > > > With stale mount units from an older /etc/fstab, users might observe > > > "interesting surprises", f.e. systemd might umount newly mounted > > > filesystems, if the in-memory mount units conflict with info in > > > /etc/fstab. > > > "" > > > > > > Apparently this is old news, I found a systemd bug report [2] > > > from 2017. It links to documentation [3] that says: > > > """ > > > On SysV systems changes to init scripts or any other files that define > > > the boot process (such as /etc/fstab) usually had an immediate effect > > > on everything started later. This is different on systemd-based > > > systems where init script information and other boot-time > > > configuration files are only reread when "systemctl daemon-reload" is > > > issued. (Note that some commands, notably "systemctl > > > enable"/"systemctl disable" do this implicitly however.) This is by > > > design, and a safety feature, since it ensures that half-completed > > > changes are not read at the wrong time. > > > """ > > > > > > Anyway I was not aware of this so I thought to share it here. > > > Further information is welcome, if you have any. > > > > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963573 > > > [2] https://github.com/systemd/systemd/issues/7291 > > > [3] https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ > > > > > > Yep, I always do a "systemctl daemon-reload" directly after editing > > these files and looking in /var/run/systemd/generator/ to see if it > > did everything right. The problem is how a user should know which > > files are affected and not. > > > > I'm personally mostly affected by /etc/fstab and /etc/crypttab, but I > > assume there are more auto-generated files. > > AFAICT neither of their man pages knows of the existence of systemctl, > and man fstab seems completely unaware of the behaviour of systemd. > The latter hardly seems surprising, as it was last updated when the > stable version was wheezy. > > These factors might be one reason why some users write that systemd > is poorly documented, or that they can't find the documentation for it. > Yes, there's copious documentation of systemd itself, but some of the > subsystems profoundly affected by it seem unaware of that in their > own documentation. > > > A while back I started writing custom systemd unit files for mounts > > and such, but now I've reverted back to using /etc/fstab directly for > > most things and then possibly just dropping in custom extra options in > > /etc/systemd/system/ if necessary. I did that because all of my > > systems run on multiple fully encrypted raid disks, and it used to be > > a mess trying systemd to understand that it has to decrypt everything > > first and then try to assemble it and mount it. These days it's much > > more clever. > > Cheers, > David. >