Re: Be careful when editing /etc/fstab
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 <deblis@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 <bouncingcats@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.
>
Reply to: