Public bug reported:
/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.
** Affects: autofs (Ubuntu)
Importance: Undecided
Status: New
--
/etc/auto.net hangs for a LONG time when NFS server is not accesible and makes
other programs unusable
https://bugs.launchpad.net/bugs/326962
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
