/etc/auto.net hangs for a LONG time when NFS server is not accesible and makes other programs unusable

[Ricardo L. Febrero]

/etc/auto.net hangs for a LONG time when NFS server is not accesible and makes other programs unusable:

When you try to list a directory with symlinks to a autofs managed NFS mounted directory, if the server is down, then you have to wait for a LONG time before the command 'ls' executes. The better is to just kill the command. The problem comes when it is an application like Gnome or wine which tries to access that directory from the background: they get stucked for a LONG time. And wine leaves it before /etc/auto.net executes 'showmount -e', which is the command that actually renders everything so slow. But I post this bug here because I think it's a failure of autofs, rather that showmount, which may have its reasons for doing this.

There should be a way of doing all this without having to wait for so long when accessing a file, which is very uncommon on Unix (normally, you can access, or not, quite fast, so applications are designed with this in mind). Maybe making the script run on a user's petition through DBus would be a good idea, then letting the applications acess it, but when it was already mounted. And, of course, during this you could do other things. Or maybe just not locking everything until you detect the server, or adding the option that you can choose the time to wait until you get the response from the server (but this is actually slow if you have to repeat an access to the disk many many times, for instance, on a script). I think that the possibility of having a DBus enabled autofs is better, just like Network Manager (what a GREAT application) does.

[Andreas Scherbaum (ads-launchpad)]

All the NFS functionality is done in the kernel, not in the userland.
So you can't even kill a command waiting for the NFS server - or to be more exact: you can kill the program but the kill will only happen after the kernel returns execution to the program.