We've also seen this bug (looping through automounted user home directories leads to errors after about the first 100 mounts). Surprisingly, this seems to be related to automount defaulting to using tcp instead of udp for its nfs mounts (nfs documentation claims udp is the default, but with autofs it seems to be the other way around, even though this doesn't seem to be documented anywhere).
It might have to do with too many sockets sitting in the TIME_WAIT state. I examined "netstat 2>/dev/null | grep TIME_WAIT | wc -l" after each loop iteration, and after around 100 mounts the number of TIME_WAITs had reached about 500 and we started getting "No such file or directory" errors. Adding multi-second sleep delays into the loop kept the TIME_WAITs count below about 150 and all mounts were successful. An alternative is to use UDP: simply add the "udp" option to the autofs mount lines (e.g., in /etc/auto.master) and restart autofs. Then no sleep delays were necessary to avoid errors. So that's two different work-arounds. But what about fixing the bugs? There are two bugs here: (1) Why does autofs default to using tcp instead of udp for nfs? Is this the way it should be? If so, it should be documented. (2) When using tcp, every automount seems to create 8 - 15 sockets that sit in TIME_WAIT for 4 minutes. With lots of automounts, this can quickly exhaust the system. Is this an automount bug, or an inherent nfs bug when using nfs over tcp? Does nfs inherently create lots of short- lived tcp connections? Alexander -- Autofs gives spurious "No such file or directory" with lots of NFS mounts, breaking a typical use pattern https://bugs.launchpad.net/bugs/65499 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
