1. 10
  1. 5

    I know this is an old article, but there’s a program called systemd-fstab-generator that translates entries from fstab into theirequivalent systemd unit files. I’m not sure it’s a good thing, but it did bite me at one point (shameless self plug).

    1. 4

      Automounters existed since the 80s but sure, let’s just reinvent the wheel… hang on a minute it’s not round any more - it’s square!

      1. 10

        yawn systemd bashing, how boring, and how expected

        anyway, this is a typical strawman response.

        automounting is not a novel concept… but noone claimed it is. the post shows how systemd nicely integrates this concept with other systemd concepts so that, for example, it becomes easy to start services that depend on such a network mount, ensuring the right ordering during boot, etc.

        1. 3

          yawn systemd bashing, how boring, and how expected

          My comment wasn’t systemd-specific - it was aimed at any solution in need of a problem - my point was that automounters have existed for well over three decades and they do well what they’re good at.

          Also, unless I’m missing something, the article describes automating an fstab(5) mount - it isn’t a real automount as in, mount on request/access and unmount if not in use, not to mention other features such us various substitutions (key, wildcard, variable, etc.), etc.

        2. 4

          None of the auto mounters I know of integrated with system service ordering and dependencies very well. Also systemd already is the place where fstab handling happens, so it effectively needs to be an (auto)mounter anyway. I don’t think reinventing the wheel criticism really applies here.

          1. 1

            I’m not the biggest fan of systemd… But I do think your comment isn’t very constructive nor a good criticism of this feature of systemd.

            1. 1

              I have moved from autofs to using the systemd built-in feature in the cases where we are automounting. The advantage is that systemd is already installed, so an additional package is not needed any more, it uses the same syntax for defining mounts as we’re already used to for services and service startup order can be nicely integrated into the auto mount availability.

              This as done away with quite a few sleep hacks in old style scripts and so far worked perfectly and did not necessitate new hacks.

              Do I need my init system to have built-in automount support? No. But it’s very convenient and very robust, so I’m more than happy to use it.

              If you are concerned by bloat or unhappy with the functionality provided by systemd, feel free to continue using autofs or anything else for your mounts.

              The one thing I wish was different is if I could have the mount and automount unit in a single file. systemd is very boilerplaty that way and while I see that in some cases the split makes sense, in my simple use cases, it’s just baggage

            2. 2

              I’m tempted to side with the autofs/automounter guys here as I think this is something that automounters are designed to handle. I don’t know systemd well enough to know what it will do when it tries to nfs mount a file system from dead, missing, or otherwise broken NFS server. The automounter is designed to gracefully handle this specific condition. I say this after having Intel dual gigabit network card fail in a TrueNAS server. From experience, a hard coded mount in /etc/fstab would cause a server to fail to come up on reboot. An autofs configuration would soft fail here with the server coming up. What should I expect systemd to do? I’m not sure. From what I understand of systemd’s design I think that the system would come up with a failed unit. Still, I prefer the automount solution here as it will release the mount when it’s not being used.

              Finally, I would note that the root cause of problems here isn’t the automounter or systemd, it’s NFS. NFS’ issue is that nfs clients tend to behave very badly when a mounted filesystem disappears because the server became unavailable. The automounter fits these situations better by limiting the lifetime of NFS mounts.