Bug 693773 - autofs continues to read obsolete misc map sources
Summary: autofs continues to read obsolete misc map sources
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: autofs
Version: 14
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Ian Kent
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-05 14:49 UTC by Raman Gupta
Modified: 2011-04-06 14:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-06 14:48:02 UTC
Type: ---


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.