In a nutshell,
- The server hostname has a large number of distinct resolutions
- autofs probes each resolution (as it is documented to do), and exactly one of two RPCs it uses for that purpose times out on every resolution of the server hostname
FWIW, the server is running the Ganesha userspace NFS stack and does not support NFS4. Server administration denies any configuration change within the relevant timeframe, but allows that routine software updates may have been applied. I am confident that neither software update nor configuration change was applied on the client side since well before the problem began manifesting.Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 6 version 0x20
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: nfs v3 rpc ping time: 0.000290
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: host nfs.my.org cost 289 weight 0
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 17 version 0x20
[... nothing until the beginning of the next probe is logged three seconds later ...]
I can work around the problem by setting use_hostname_for_mounts = "yes" setting in /etc/autofs.conf, but inasmuch as that skips probing altogether (as I understand it), it seems to gives up many of the advantages that a multiheaded NFS server such as ours provides.
Questions:
- Is there a plausible client-side explanation for the behavior change?
- Even if not, then is there a client-side solution other than turning off probing altogether?