Suppose I have an NFS client with an NFS share mounted at /nfs_share.
Suppose I unplug the NFS server, causing an ungraceful shutdown.
Now my client's /nfs_share is stale.
If on the client I go into a bash prompt and type
ls /nfs_<TAB> then my bash shell freezes. It appears to be stuck in a syscall.
Just reading / to look up what entries might match "/nfs_" ought not block on an unresponsive file system as we are reading the entries in the / filesystem, not the entries in the NFS filesystem mounted at /nfs_share.
The freeze would only happen if tab completion is causing bash (or something else) to read the props of the NFS F/S.
So I wounder if anyone knows what is hitting the NFS filesystem?* And can I configure the system to not try to read the properties of the mounted filesystem when just doing a string match to do tab completion?
I remember in the past (years ago), perhaps on a different distro, hitting a stale NFS mount would generate an error message and a non-zero exit code, and promptly at that.
*) This behaviour to me has the feeling of some part of systemd trying to "optimize" things by caching filesystem info. If so, OK - but how can I turn it off?