On Thu, 2019-11-07 at 15:57 +0100, Simon ELBAZ wrote:
Hi,
I am working on an autofs issue.
Linux kernel: 2.6.18-398.el5
autofs: autofs-5.0.1-0.rc2.184.el5
This is really, really old, but not quite as old as I thought.
* Fri Jul 11 2014 Ian Kent <ikent@xxxxxxxxxx> - 5.0.1-0.rc2.184.el5
- bz1049017 - Regression: autofs mounts hang if maps are reloaded
while the
mount is expiring
- check for existing offset mount before mounting.
- Resolves: rhbz#1049017
The latest revision is 186 but that doesn't look like it would help.
* Mon Feb 27 2017 Ian Kent <ikent@xxxxxxxxxx> - 5.0.1-0.rc2.186.el5
- bz1130829 - Memory leak in get_exports
- fix package revision in spec file.
- Related: rhbz#1130829
* Wed Feb 08 2017 Ian Kent <ikent@xxxxxxxxxx> - 5.0.1-0.rc2.185.el5
- bz1130829 - Memory leak in get_exports
- fix memory leak in get_exports().
- Resolves: rhbz#1130829
There are 2 RHEL 5.11 servers accessing an NFS server.
They are rebooted every morning.
Sometimes, during the day, autofs hangs up on both servers. When one
of
the server is rebooted, the other autofs can resume its NFS access.
I'm not sure what this means, how about we call machines on which
autofs is running clients and NFS servers they are trying to mount
from servers.
I am focusing on the /HOME/svsi_emr offset to debug the issue.
Again, don't know what that means, no information on it.
I suggested the customer to update the kernel to 2.6.18-419.el5
version
but without being sure it will solve the issue.
The autofs is in debug mode. Logs are available.
I can look at the logs but even though the last updates are fairly
recent this is really old and upstream is usually focused on recent
revisions.
Even if you log a bug at bugzilla.redhat.com and we work out what
the problem is getting that into a release will be like pulling
teeth at this point of the RHEL-5 life cycle.
Ian
