← Back to context

Comment by simoncion

1 day ago

> How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"?

The '_netdev' option works a treat on sane systems. From mount(8):

       _netdev
           The filesystem resides on a device that requires network access
           (used to prevent the system from attempting to mount these
           filesystems until the network has been enabled on the system).

It should work on SystemD and is documented to in systemd.mount

  Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount.

but -surprise surprise- it doesn't reliably work as documented because SystemD is full of accidental complexity.

7 comments

simoncion

Reply
jdub  1 day ago

Sure, and systemd would translate that directly into a dependency on network startup, which is precisely equivalent to the approach I mentioned that depends on operator knowledge. It's configuration, not "just works" inference.

  • simoncion  1 day ago

    > Sure, and systemd would translate that directly into a dependency on network startup...

    You'd think so, but the Github Issue linked by GP shows that the machinery is unreliable:

      In practice, adding `_netdev` does not always force systemd to [consider the mount unit a network mount], in some instances even showing *both* local and remote ordering. ... This can ultimately result in dependency cycles during shutdown which should not have been there - and were not there - when the units were first loaded.

    > ...not "just works" inference.

    Given that SystemD can't reliably handle explicit use of _netdev, I'd say it has no hope of reliably doing any sort of "just works" inference.

    • jdub  1 day ago

      It's so refreshing to discover that the "I found one bug in systemd which invalidates everything" pattern continues in the year of our lord 2026.

      4 replies →