Typical problem with network mounts is remote equipment not being
available when our host boots up after a power failure. Even if you
properly configure boot order of all local services and wait for link
coming up on your NIC, you still may boot faster than some intermediate
switch on the network or the DNS server itself. Let's refer to this as a
"server room boot race". For NFS mounts with hostname in hosts(5) the
race is addressed by a retry loop on NFS mount timeout. However, a DNS
resolution timeout is treated differently to NFS mount timeout. We fail
on the former and keep retrying on the latter.
With feedback received on current@, I see that the problem is so old, that
people got used to it and see it as a desired behavior rather than a
problem. And for those who is affected by the problem, they suggest
hosts(5) as a solution. Note that using hosts(5) isn't scalable, and
using bare IP addresses is neither scalable, nor compatible with
Kerberized mounts.
A trade-off solution would be to enable the retry cycle over DNS timeouts
only when background mode is specified, which is a typical use in fstab(5)
and very uncommon in a command line. That would address the server room
boot race problem without breaking POLA for command line.
One remaining problem is that our resolver doesn't differentiate between
negative answer from DNS server and a timeout. Once resolver is fixed we
should check only EAI_AGAIN error and exit retry cycle on EAI_NONAME.
Until this is fixed, we have a bug that a mistyped hostname in your
fstab(5) would end in endless attempts to resolve it. This is a lesser
evil than a host with a correctly written hostname in fstab(5) coming up
without necessary mounts due to the boot race. And the resolver is going
to be fixed eventually.