Description of problem: Map expiry doesn't work with file maps. File maps are only re-read if the requested key is not found in the current map and the map has been modified since the map was initially read. This doesn't account for changed entries, only added/removed ones. Version-Release number of selected component (if applicable): autofs-4.1.3-47 How reproducible: Always Steps to Reproduce: 1. Set two entries in /etc/auto.misc with same key but different mounts 2. Comment one of them out 3. access the mountpoint 4. manually umount the mntpoint 5. uncomment the commented one, comment the uncommented one (switch them) in auto.misc 6. access the mountpoint Actual results: You'll get the same mount as the first time even though the map has changed Expected results: Second access gets new mount Additional info: This is broken off of 137206. Here's a potentially relevant remark from that bug: Comment #16 From Dave Lehman (dlehman) on 2005-02-04 12:11 EST [reply] Private Jeff, expiry with file maps doesn't work. The thing is that NIS maps get queried with every request, so the cache is updated every time, effectively eliminating the benefit of caching the NIS maps AFAICT. File maps, OTOH, are only re-read if a) the requested key/entry is not found *and* b) the file has been modified since it was initialized. I started putting a patch together to re-read the file maps whenever the file has been modified, but I found that there's no good way to update the timestamp in the lookup_context struct defined in modules/lookup_file.c. What this means is that if the map has been modified at all since the automounter initialized the map (daemon startup or SIGHUP) it will be re-read for every request. Again, this voids the cache. Let me know if you want me to upload the patch.
A patch for this is being worked on upstream. We have hashed out many of the problems with it and it is on target for U5.
A fix for this has been committed to U5. Packages versioned 4.1.3-104 and later have the fix.
I'm closing this as fixed. If testing proves otherwise, then please reopen the bug.