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.
