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
