Suse 10.2 autofs not working reliably
 

I have a Suse 10.2 box running autofs5-5.0.2-0.3 which automounts 400+ machines in different subnets. there a bunch of cron jobs that access these mounts. found that the jobs fail intermittently with 'no such file or directory' when going to various mount points. right after that, I cd to that dir do an 'ls' and the mount is fine. Seems I stopped this by setting timeout=0 {do not unmount} on the automounts. but this seems rather counter to the purpose of automount, plus I'm concerned as to how this may effect the system performance, etc over time.

since doing this, I see some occasional/transient "NFS Stale file handle" from jobs, but again, you go to the mount point and it's all good.

Has anyone seen similar?

This same setup runs on a Solaris box without issue.

I've had a similar problem, if "things don't work too well in 10.2 anymore" counts as "similar". The last time I checked 10.3 was supported. Is there any chance of upgrading to that?

Can you shed more detail on the similar problem you experienced? I don't have a hard stop/rule against upgrading to Suse 10.3, but I want to do it only if there is a known fix for automount and not just upgrade to see if it fixes the problem. Do you have some evidence?

thanks

I'm sorry, I can't help you w/autofs, quite. It's just that getting things to run in 10.2 is very difficult often. I haven't been able to find any repositories that are still active, so there are no updates to get. This might not be such a problem if you'd been keeping updates regularly when they were available, but what happens when you want to install a new package from your distro discs, but it's way out-of-date?
I've used both 10.2 and 10.3, and from my experience, there was nothing to prefer in 10.2. However if you do find that 10.3 is unacceptable, you won't be able to go back to the 10.2 system you had, unless you are running it in a virtual machine, and you've taken snapshots.

Sorry, forget what I said about upgrading to 10.3. I just read that support for it has been discontinued for almost a month. If you do find yourself an iso, and upgrade using it, you will undoubtedly have a world of headaches, having a system full of packages that are completely unupdated.

pretty sure solved.
 

increased the # of available ports for use by NFS by lowering kernel parameter 'sunrpc.min_resvport' to 200. it was 650 prior. left 'sunrpc.max_resvport' at 1023.
did this dynamically with 'sysctl -w sunrpc.min_resvport=200'

add 'sunrpc.min_resvport=200' to /etc/sysctl.conf so system gets it on reboot.

meant to get back to this, yes, increasing the number of ports allocated for NFS resolve my issue, though you can run into conflicts with other ports, such as samba; port 445 which you have to watch out for. though newer patch levels of the Suse 10.2 kernel include a parameter; 'sunrpc.max_shared' which allow you to multiplex several multiple NFS connections over the same port. Default value is 1, but you can increase accordingly.

sunrpc.max_shared in 2.6.16.60-0.33
 

I found that the kernel-bigsmp-2.6.16.60-0.33 includes the sunrpc.max_shared kernel parameter.

Sorry to resurrect this thread.

I am also having this issue on my SUSE SLES 10 SP2 box. At times when running my jobs, I will get a 'no such file or directory' error. But when I cd into the directory, the file is there. Running it the second time passes fine.

Here are my sysctl settings by default.
suse9:~ # sysctl -a | grep -i sunrpc.max_shared
sunrpc.max_shared = 1
suse9:~ # sysctl -a | grep -i 'sunrpc.min_resvport'
sunrpc.min_resvport = 665

The solution call for lowering 'sunrpc.min_resvport' to 200. Any suggestion for the max? It is currently set to 1...

Can someone explain what the 2 kernel parameters play a role in this issue?


Thanks much everyone...

I strongly recommend you create a new thread since your problem seems different and it will attract more attention.