Re: Be careful when editing /etc/fstab
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 signature.asc Description: PGP signature
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. 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. On Wed, Jun 24, 2020 at 3:51 PM David Wright wrote: > > On Wed 24 Jun 2020 at 09:32:53 (+0200), Anders Andersson wrote: > > On Wed, Jun 24, 2020 at 1:17 AM David 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. >
Re: Be careful when editing /etc/fstab
On Wed 24 Jun 2020 at 09:32:53 (+0200), Anders Andersson wrote: > On Wed, Jun 24, 2020 at 1:17 AM David 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.
Re: Be careful when editing /etc/fstab
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
Re: Be careful when editing /etc/fstab
On Wed, Jun 24, 2020 at 1:17 AM David 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.
Re: Be careful when editing /etc/fstab
On Wed, 24 Jun 2020 at 09:16, David 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
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/
