zlacker

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

>>simonc+(OP)
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.

>>jdub+Ua
> 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.

>>simonc+4c
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.

>>jdub+6j
I saw many corner cases in systemd over the years. And to echo the other poster in this thread, they typically are known, have Github issues, and are either ignored or have a LOLNO resolution.

And I'm not a systemd hater. I very much prefer it to the sysv mess that existed before. The core systemd project is solid. But there is no overall vision, and the scope creep resulted in a Cthulhu-like mess that is crashing under its own weight.

>>jdub+6j
> "I found one bug in systemd which invalidates everything"

I'll refer back to the story of Van Halen's "no brown M&Ms" contract term and the reason for the existence of that term and ones like it.

"Documented features should be reasonably well-documented, work as documented, and deviations from the documentation should either be fixed or documented in detail." is my "no brown M&Ms" for critical infrastructure software. In my professional experience, the managers of SystemD are often disinterested in either documenting or fixing subtle bugs like the one GP linked to. I find that to be unacceptable for critical infrastructure software, and its presence to be indicative of large, systemic problems with that software and how work on it is managed.

I really wish SystemD was well-managed, but it simply isn't. It's a huge project that doesn't get anywhere near the level of care and giveashit it requires.

>>jdub+6j
Just one bug? No, there's way more than that.