Re: Be careful when editing /etc/fstab
On Wed, Jun 24, 2020 at 1:17 AM David <bouncingcats@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.
Reply to: