Bug 108883 – Autofs fails to release cached mount paths and acknowledge new paths from NIS.

• Product: Gentoo Linux
• Status: RESOLVED TEST-REQUEST

[Description Darren Miller 2005-10-11 09:17:17 UTC]

Basic problem appears to be associated with Autofs and cached mount paths, NIS 
updates a mount path automatically and autofs is supposed to timeout its cache 
and resync to the new path.  However either the timeout is excessively long or 
it's failing to timeout at all.  in either case it results in a server error 
message with path not found, since it's looking in the wrong place for the data 
the error is correct, but ypcat reports the correct location.  

<Extract from RedHat Bug Logs>
race between mounting a share and updating the cache in the parent
process. If the mount completed first, the parent would not expire the
stale entry, leaving it first on the list. This causes map updates to not
be recognized (well, worse, they are recognized after the first expire, but
not subsequent ones). 

Reproducible: Always
Steps to Reproduce:
1.for an existing mount, change the autofs map and push to all NIS slaves
2.on a system whereby the old map existed, check the mount with ypcat
3.cd into the directory you changed and record if the mounted location is the 
correct one, or would have been stale had you actually moved it. 




Details section references a RedHat bug log which has the same symptoms.  I am 
seeing this bug on my Gentoo systems but the redhat servers have been fixed 
with a newer revision.

Reproducible: Always
Steps to Reproduce:
1.Automount a location from within NIS on a fileserver
2.user that location for a bit.
3.while in use, change the location on the fileserver
4.update the NIS files and push the new map to all NIS Slaves
5.check the location has altered by examining the map from the mounting server 
(ypcat)
6.attempt to cd  into the premounted location

Actual Results:  
gbrsoupss1xxss1 ~ # ypcat -k auto.user.nxa | grep ccm_root
ccm_root netapp72:/vol/vol2/ccm_root/ccm_root

gbrsoupss1xxss1 ~ # cd /user/ccm_root
-bash: cd: /user/ccm_root: No such file or directory

gbrsoupss1xxss1 ~ # tail -10 /var/log/syslog
Oct 11 18:05:49 gbrsoupss1xxss1 automount[22208]: mount(nfs): nfs: mount 
failure netapp72:/vol/vol2/Users9/ccm_root on /user/ccm_root
Oct 11 18:05:49 gbrsoupss1xxss1 automount[22208]: failed to mount /user/ccm_root



Expected Results:  
gbrsoupss1xxss1 ~ # ypcat -k auto.user.nxa | grep ccm_root
ccm_root netapp72:/vol/vol2/ccm_root/ccm_root

gbrsoupss1xxss1 ~ # cd /user/ccm_root
gbrsoupss1xxss1 ccm_root # 

No error reported in the syslog.



gbrsoupss1xxss1 ~ # emerge info
Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r1, 
2.6.11-gentoo-r5 i686)
=================================================================
System uname: 2.6.11-gentoo-r5 i686 Intel(R) Pentium(R) III CPU family      
1400MHz
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5-r2
sys-apps/sandbox:    1.2.11
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.4.3-r4, 1.5.18-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X1
1/xkb /usr/share/config /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk 
ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://phaldor/gentoo-portage"
USE="x86 X alsa apm arts avi berkdb bitmap-fonts crypt cups eds emboss encode 
foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imlib ipv6 jpeg kde 
libg++ libwww mad mikmod motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss 
pam pdflib perl png python qt quicktime readline samba sdl spell ssl tcpd tiff 
truetype truetype-fonts type1-fonts vorbis xml2 xmms xv zlib userland_GNU 
kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY

[Comment 1 Darren Miller 2005-10-11 09:21:50 UTC]

This machine serves samba to a site of 2000 people using autofs to a 6TB NAS 
filer.  So when this problem occurs it's a bit of a show stopper since the only 
way to resolve the issue is to reboot the box.

[Comment 2 Lintula 2006-01-24 03:42:16 UTC]

> Basic problem appears to be associated with Autofs and cached mount paths, NIS 
> updates a mount path automatically and autofs is supposed to timeout its cache 
> and resync to the new path.  However either the timeout is excessively long or 
> it's failing to timeout at all.  in either case it results in a server error 
> message with path not found, since it's looking in the wrong place for the data 
> the error is correct, but ypcat reports the correct location.  

We don't use NIS, but /etc/autofs/* files distributed by cfengine. Any changes in the files seem to still get completely ignored by autofs until the next reboot. Probably the same bug?

[Comment 3 Lintula 2006-01-25 02:22:21 UTC]

(In reply to comment #2)
> We don't use NIS, but /etc/autofs/* files distributed by cfengine. Any changes
> in the files seem to still get completely ignored by autofs until the next
> reboot. Probably the same bug?

Upgrading to autofs 4.1.4+patches fixed this problem for me. There is no ebuild yet, though, at least not in the portage tree.

[Comment 4 Darren Miller 2007-01-17 11:20:27 UTC]

> Upgrading to autofs 4.1.4+patches fixed this problem for me. There is no ebuild
> yet, though, at least not in the portage tree.

Any news on ebuild availability?

[Comment 5 Stefaan De Roeck (RETIRED) 2008-02-03 11:39:50 UTC]

New maintainer, net-fs/autofs-5.0.3-r1 is now in the tree.  

[Comment 6 Stefaan De Roeck (RETIRED) 2008-02-03 12:19:57 UTC]

Is there still a reason to put autofs-4.1.4 into the tree?  Or is autofs-5 a viable option as well?
Please test, any feedback is welcome.  

[Comment 7 Someone Else Who Won't Be Here 2008-02-17 20:54:11 UTC]

You asked about whether 5.x is viable, here is what I've seen:

autofs-5.x segfaults when starting during loading my existing nis-shared automount map. The map sytax was/is correct and works with 4.1.x.  Looking for docs explaining some difference that it expects.

Feb 17 06:18:48 quevedo automount[24140]: syntax error in map near [ /homes/taka ]
Feb 17 06:18:48 quevedo automount[24140]: segfault at 00000000 eip b7edf7ca esp bfdbc63c error 4

# ypcat -k auto.cv |grep taka
taka -rw,soft senna.cv.ri.cmu.edu:/homes/taka

[Comment 8 Stefaan De Roeck (RETIRED) 2008-02-18 13:44:39 UTC]

(In reply to comment #7)
> Feb 17 06:18:48 quevedo automount[24140]: syntax error in map near [
> /homes/taka ]
> Feb 17 06:18:48 quevedo automount[24140]: segfault at 00000000 eip b7edf7ca esp
> bfdbc63c error 4

Could you test against the latest net-fs/autofs-5.0.3-r2 and see if that works?  If it doesn't, a new bug report on this may be in order...

[Comment 9 Stefaan De Roeck (RETIRED) 2008-03-25 12:08:10 UTC]

No feedback in well over a month, closing bug.