Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #223919 > unrolled thread

Be careful when editing /etc/fstab

Back to article view | Back to linux.debian.user

Contents

  Be careful when editing /etc/fstab David <bouncingcats@gmail.com> - 2020-06-24 01:20 +0200
    Re: Be careful when editing /etc/fstab David <bouncingcats@gmail.com> - 2020-06-24 02:00 +0200
    Re: Be careful when editing /etc/fstab Anders Andersson <pipatron@gmail.com> - 2020-06-24 09:40 +0200
      Re: Be careful when editing /etc/fstab songbird <songbird@anthive.com> - 2020-06-24 11:50 +0200
      Re: Be careful when editing /etc/fstab David Wright <deblis@lionunicorn.co.uk> - 2020-06-24 16:00 +0200
        Re: Be careful when editing /etc/fstab Anders Andersson <pipatron@gmail.com> - 2020-06-24 19:10 +0200
          Re: Be careful when editing /etc/fstab Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-25 07:50 +0200

#223919 — Be careful when editing /etc/fstab

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/

[toc] | [next] | [standalone]

#223920

On Wed, 24 Jun 2020 at 09:16, David <bouncingcats@gmail.com> wrote:

> Anyway I was not aware of this so I thought to share it here.
> Further information is welcome, if you have any.

Well, it appears there is more info out there if you know to
look for it. For example:

https://unix.stackexchange.com/questions/477794/how-to-force-os-reload-of-fstab

https://unix.stackexchange.com/questions/90723/is-there-any-reason-to-move-away-from-fstab-on-a-systemd-system

[toc] | [prev] | [next] | [standalone]

#223932

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.

[toc] | [prev] | [next] | [standalone]

#223943

Anders Andersson wrote:
...
> 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.

  and then there are those of us who keep things simple 
and don't need all this complexity or interference.

  when i edit /etc/fstab i don't expect or want any
changes to happen to file systems until i reboot or 
manually unmount and remount a file system.

  to me having a system interfere in what i'm doing
is annoying and wrong - i consider it a bug.


  songbird

[toc] | [prev] | [next] | [standalone]

#223954

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.

[toc] | [prev] | [next] | [standalone]

#223960

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.
>

[toc] | [prev] | [next] | [standalone]

#223983

[Multipart message — attachments visible in raw view] — view raw

On Mi, 24 iun 20, 19:07:40, Anders Andersson wrote:
> 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.

Most documentation comes from upstream.

Debian Developers are already doing a lot in this regard, e.g. by 
writing man pages where missing (as per Debian Policy requirement).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web