4 ms·

So, a lot of that sounds like philosophical disagreement. The one practical concern in there is "I worry that one day when I update my debian box, things are go

So, a lot of that sounds like philosophical disagreement. The one practical concern in there is "I worry that one day when I update my debian box, things are going to be super broken", and it appears that by "broken" you mean "requiring systemd". I still don't understand what the problem is.

digi_owl 11y ago
How is this for practical: Update box, get systemd, fail to boot because of a fstab entry you barely remember was there that was acceptable to mount for years, but systemd stops the boot dead on. Or stall on reboot/shutdown because they still can't get straight that NFS is a mount over the network, and so needs to be unmounted before taking the network down. their DNS client that quietly grew a cache was found to be susceptible to cache poisoning. A issue that has been known about and protected against for a decade by more mature DNS implementations. And i think their dhcp client (yep, it has that to) ignores a bunch of best practices/security in the name of speed. The whole edifice is a NIH of cards. This even though the project leadership is supposedly very keen on security...
- the_why_of_y 11y ago
  Systemd correctly implements the "noauto" and "nofail" keywords in fstab(5) in the way they have always been documented: if neither of these is specified for a filesystem, then that file system will be mounted at boot time and a failed attempt to mount that filesystem implies a boot failure. The fact that previous init scripts gladly ignored these failures does not reflect negatively on systemd but on those init scripts. By the way, FreeBSD has the same options, except that "nofail" is called "failok".
  - digi_owl 11y ago
    Odd, i find nothing in the fstab man file about nofail. And all that the mount man file says on it is that it suppresses error messages. Neither dictates any specific behavior when said errors show up.
    - the_why_of_y 11y ago
      Ok, it is younger than I thought, it was added in 2008 so more conservative veteran UNIX admins might not have heard of it: Util-linux-ng 2.14 Release Notes (09-Jun-2008) ============================================== Release highlights ------------------ mount(8) supports new "nofail" mount option. Then it wasn't documented for 2 years, the commit that adds it to the fstab.5 man page is from 2010: https://github.com/karelzak/util-linux/commit/abe3d704b6aeb6b82ff32e8599edb56525cdfd72 https://github.com/karelzak/util-linux/commit/abe3d704b6aeb6... Interestingly, it pre-dates the similar FreeBSD parameter by 3 years: https://svnweb.freebsd.org/base?view=revision&revision=222832 https://svnweb.freebsd.org/base?view=revision&revision=22283... Add a special mount option "failok" to indicate that the administrator wants the system to proceed to boot without bailing out into single user mode, even when the file system can not be successfully mounted. Oh and people are of course invited to down-vote me again, I've got karma to burn, and the evidence that systemd is doing things in exactly the same way as FreeBSD clearly needs to be suppressed if we want to maintain our regular rituals of pointless outrage on this site.
      - digi_owl 11y ago
        And the fstab line is a copy and paste of the mount line on nofail. Basically it just suppresses the error code, and do not dictate any behavior for the larger system.
toast0 11y ago
I'm not necessarily worried about 'requiring systemd', I'm more worried about requiring systemd-component X where component X replaces an existing service I had installed, and is a broken reimplementation, leading to system doesn't boot, doesn't bring up network, doesn't respect my previous settings, shares my data with the world, is susceptible to security bugs that were fixed in mainstream implementations many years ago, etc.

digi_owl 11y ago

How is this for practical: Update box, get systemd, fail to boot because of a fstab entry you barely remember was there that was acceptable to mount for years, but systemd stops the boot dead on. Or stall on reboot/shutdown because they still can't get straight that NFS is a mount over the network, and so needs to be unmounted before taking the network down. their DNS client that quietly grew a cache was found to be susceptible to cache poisoning. A issue that has been known about and protected against for a decade by more mature DNS implementations. And i think their dhcp client (yep, it has that to) ignores a bunch of best practices/security in the name of speed. The whole edifice is a NIH of cards. This even though the project leadership is supposedly very keen on security...

the_why_of_y 11y ago
Systemd correctly implements the "noauto" and "nofail" keywords in fstab(5) in the way they have always been documented: if neither of these is specified for a filesystem, then that file system will be mounted at boot time and a failed attempt to mount that filesystem implies a boot failure. The fact that previous init scripts gladly ignored these failures does not reflect negatively on systemd but on those init scripts. By the way, FreeBSD has the same options, except that "nofail" is called "failok".
- digi_owl 11y ago
  Odd, i find nothing in the fstab man file about nofail. And all that the mount man file says on it is that it suppresses error messages. Neither dictates any specific behavior when said errors show up.
  - the_why_of_y 11y ago
    Ok, it is younger than I thought, it was added in 2008 so more conservative veteran UNIX admins might not have heard of it: Util-linux-ng 2.14 Release Notes (09-Jun-2008) ============================================== Release highlights ------------------ mount(8) supports new "nofail" mount option. Then it wasn't documented for 2 years, the commit that adds it to the fstab.5 man page is from 2010: https://github.com/karelzak/util-linux/commit/abe3d704b6aeb6b82ff32e8599edb56525cdfd72 https://github.com/karelzak/util-linux/commit/abe3d704b6aeb6... Interestingly, it pre-dates the similar FreeBSD parameter by 3 years: https://svnweb.freebsd.org/base?view=revision&revision=222832 https://svnweb.freebsd.org/base?view=revision&revision=22283... Add a special mount option "failok" to indicate that the administrator wants the system to proceed to boot without bailing out into single user mode, even when the file system can not be successfully mounted. Oh and people are of course invited to down-vote me again, I've got karma to burn, and the evidence that systemd is doing things in exactly the same way as FreeBSD clearly needs to be suppressed if we want to maintain our regular rituals of pointless outrage on this site.
    - digi_owl 11y ago
      And the fstab line is a copy and paste of the mount line on nofail. Basically it just suppresses the error code, and do not dictate any behavior for the larger system.

toast0 11y ago

I'm not necessarily worried about 'requiring systemd', I'm more worried about requiring systemd-component X where component X replaces an existing service I had installed, and is a broken reimplementation, leading to system doesn't boot, doesn't bring up network, doesn't respect my previous settings, shares my data with the world, is susceptible to security bugs that were fixed in mainstream implementations many years ago, etc.