Bug 693773

Summary:	autofs continues to read obsolete misc map sources
Product:	[Fedora] Fedora	Reporter:	Raman Gupta <rocketraman>
Component:	autofs	Assignee:	Ian Kent <ikent>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	14	CC:	ikent
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-04-06 14:48:02 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Raman Gupta 2011-04-05 14:49:25 UTC

Description of problem:

I often get these messages from automount in /var/log/messages:

Mar 21 13:27:38 xxx automount[30662]: key "oldmount1" not found in map
source(s).
Mar 21 13:27:38 xxx automount[30662]: key "oldmount2" not found in map
source(s).
Mar 21 13:27:38 xxx automount[30662]: key "oldmount3" not found in map
source(s).
Mar 21 13:28:40 xxx automount[30662]: key "oldmount1" not found in map
source(s).
Mar 21 13:28:40 xxx automount[30662]: key "oldmount2" not found in map
source(s).
Mar 21 13:28:40 xxx automount[30662]: key "oldmount3" not found in map
source(s).
Mar 22 11:11:37 xxx automount[30662]: key "oldmount2" not found in map
source(s).
Mar 22 11:11:37 xxx automount[30662]: key "oldmount3" not found in map
source(s).
Mar 22 11:11:37 xxx automount[30662]: key "oldmount1" not found in map
source(s).

oldmount1/2/3 are NFS mounts from a machine that no longer exist since
the source machine was turned off. These mounts previously existed in auto.misc as follows:

oldmount1      -rw,soft,intr           oldmachine:/
oldmount2      -ro,soft,intr           oldmachine:/foo
oldmount3      -rw,soft,intr           oldmachine:/bar

These mounts were moved into /etc/fstab as full-time mounts and therefore removed from auto.misc. The machine was subsequently replaced and /etc/fstab entries changed.

Currently none of the /etc/auto.* files reference "oldmachine" at all, nor does /etc/fstab since fstab now refers to the new machine.

Even reboots have not helped -- oldmount1/2/3 have not existed for a
few months now.


Version-Release number of selected component (if applicable):

autofs-5.0.5-31


How reproducible:

Presumably this can be reproduced by using an NFS mount via auto.misc, but then deleting it from auto.misc and adding it to /etc/fstab.


Steps to Reproduce:
1. Create an NFS mount in auto.misc.
2. Use it with autofs.
3. Delete it from auto.misc and add it to /etc/fstab.
4. Wait for autofs to complain about it not being found in the map sources.

Comment 1 Ian Kent 2011-04-06 04:11:15 UTC

I'm struggling to see how this is a bug.

If an attempt is made to access a path the kernel is duty
bound to try and look it up since it cannot know if the
path is valid or not. Similarly, if that path is within
an automount managed directory, autofs is duty bound to
try and lookup the mount and mount it. If no map entry
is found, because the map has changed or the entry never
existed (or some other problem occurs) then the request
fails.

This annoying log message was requested to be added by
someone else and one reason for it was to help track down
applications that were continually attempting to access
stale map entries. If you enable debug logging the pid of
the requesting process is logged which may help identify
why this is happening. You can find out how to go about
setting up debug logging at http://people.redhat.com/jmoyer.

Of course I may be wrong about the situation and await your
advice on that.

Ian

Comment 2 Raman Gupta 2011-04-06 14:48:02 UTC

Ah, I see what you are saying -- some other application is trying to access that path, thus causing automount to report that it does not exist. Ok -- that makes sense.

Might I suggest a small change to the log message that would make things a bit clearer?

pid '222' requested key not in map source(s): "oldmount1".

This way, it is clear that it is an external process trying to access that mount as opposed to automount itself, and gives the PID of that process, which is very useful, without having to enable debug logging.

Sorry for the noise -- I posted on the users list first to get exactly this type of information, but didn't get any response.