On Wed, Jun 24, 2020 at 1:17 AM David <bouncingc...@gmail.com> wrote: > > Hi, > > 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. 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.
