Bug 218546 - NFS/AutoFS fails to accurately report non-existent mount points
NFS/AutoFS fails to accurately report non-existent mount points
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: autofs (Show other bugs)
4.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brock Organ
: OtherQA, Reopened
: 229374 (view as bug list)
Depends On:
Blocks: 224092 224093 228144
  Show dependency treegraph
 
Reported: 2006-12-05 17:41 EST by Terry Rudd
Modified: 2009-06-19 06:25 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2007-0734
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 11:02:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to report failed lookups (1.44 KB, patch)
2007-01-23 14:12 EST, Jeffrey Moyer
no flags Details | Diff

  None (edit)
Description Terry Rudd 2006-12-05 17:41:46 EST
Description of problem:
AutoFS message logged to /var/log/messages is misleading and not specific enough
to troubleshoot problem. If a mountpoint does not exist in an automounter map,
and an attempt to cd into that directory is made, the message logged in messages is:
      Jan 31 16:46:31 carp automount[6127]: failed to mount
      /auto/home/.view.dat
While true, this message should state more accurately that the entry was not
found in the "map" itself, not that some problem happened with the mount or
mount protocol.  The current message can lead to a lot of wasted time trying to
diagnose and fix a problem that does not exist - such as a problem with mount,
the mount protocol, or the network

Version-Release number of selected component (if applicable):
RH AS 3 & AS 4


How reproducible:
Pretty simple based on information above.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Unexpected error trying to cd to expected mount point


Expected results:
Mount point not in automount file

Additional info:
Aware that Red Hat feels customer could use strace to solve this but our
customer in Europe is very dis-satisfied with that answer and they are pushing
hard on HP Support to drive to get this fixed.

Also see IT 106775
Comment 1 Jeffrey Moyer 2006-12-05 17:46:09 EST
I agree that better error reporting is needed.  I think we should address this.
Comment 2 Jeffrey Moyer 2007-01-11 13:25:08 EST
In this particular case, however, .view.dat most likely matched the wild-card
key;  otherwise, autofs would not have attempted to mount it at all.  Could you
attach your maps so I can verify this?
Comment 3 Terry Rudd 2007-01-16 16:05:37 EST
(In reply to comment #2)
> In this particular case, however, .view.dat most likely matched the wild-card
> key;  otherwise, autofs would not have attempted to mount it at all.  Could you
> attach your maps so I can verify this?

Jeffrey, I am asking for this information from the field engineer now.    I am
also resubmitting this defect, along with my others to comply with the new
HP/Red Hat requirements tracking effort.   I just don't want you to think I plan
to work this defect on two fronts :-)   I think this one will go away in favor
of the new one.  I will try to find the maps you require ASAP.
Comment 4 Jeffrey Moyer 2007-01-17 12:11:57 EST
I've reevaluated this request and have decided that this is not a problem that
needs addressing.  The failed mount attempt is logged in the system log, and
shows clearly that the mount command failed.  This indicates that a map entry
was found,  but the actual mount did not succeed.  That is enough information to
investigate the cause of the failure.
Comment 5 James Hofmeister 2007-01-17 16:55:51 EST
Here is additional documentation from our customer:

Brief summary of requested functionality:
 AutoFS message logged to /var/log/messages is misleading and not specific 
enough to troubleshoot problem.

Further technical details:
 If a mountpoint does not exist in an automounter map, and an attempt to cd 
into that directory is made, the message logged in messages is:
     Jan 31 16:46:31 carp automount[6127]: failed to mount
     /auto/home/.view.dat
 While true, this message should tell more specifically that the entry was not 
found in the ?map? itself, not that some problem happened with the mount or 
mount protocol.

 On my system, I do the same thing and I get:
   Feb 26 18:02:43 hpnec08 automount[21073]: attempting to 
   mount entry /misc/not_there
   Feb 26 18:02:43 hpnec08 automount[21275]: lookup(file): lookup
   for not_there failed
 
 This is useful information as it directs me to look at my maps, and not look 
at some other networking problem.

Here is the problem duplication:

========================================================================= 
=======
I was able to reproduce it om my system (RHEL3U5) 

NFS server = lucky.bel.hp.com with /home exported

# cat /etc/auto.master
/auto/home      /etc/auto.home

# cat /etc/auto.home
tomvdb -fstype=nfs,soft        lucky.bel.hp.com:/home:tomvdb
scholdis -fstype=nfs,soft        lucky.bel.hp.com:/home

# /etc/init.d/autofs restart
I have put -v into /etc/sysconfig/autofs    DAEMONOPTIONS="--timeout=60 -v"

Good mount
# cd /auto/home/tomvdb
Aug 17 23:45:40 localhost automount[4481]: attempting to mount 
entry /auto/home/tomvdb

Bad mount
# cd /auto/home/test

Aug 17 23:48:10 localhost automount[4481]: attempting to mount 
entry /auto/home/test Aug 17 23:48:10 localhost automount[4598]: failed to 
mount /auto/home/test

"test" is not a key in the auto.home file, so no mount should be done.
In HPUX no mount attempt is done!!!!!!! See attached txt file: HPUX automount 
behavior.txt

I installed the autofs source RPM and recompiled...

See the automount source code: (automount.c) Line 1091

Vi /usr/src/redhat/SOURCES/autofs-4.1.4/daemon/automount.c
--------
                       err = ap.lookup->lookup_mount(ap.path,
                                                     pkt->name, pkt->len,
                                                     ap.lookup->context);

                       /*
                        * If at first you don't succeed, hide all
                        * evidence you ever tried
                        */
                       if (err) {
                               error("failed to mount %s", buf);
                               umount_multi(buf, 1);
                               if ((!ap.ghost) ||
                                   (ap.state == ST_SHUTDOWN_PENDING
                                    || ap.state == ST_SHUTDOWN))
                                       rm_unwanted(buf, 1, 0);
                       }

The error message should give: Failed to lookup key in map /etc/auto.home Or 
something alike....
========================================================================= 
=======

Other information (justification, etc) from customer for consideration:

Here is a log from hp-ux:
========================================================================= 
=======
Mounting existing jochemv
==========================

Nov  6 17:33:15 t21305  LOOKUP REQUEST: Mon Nov  6 17:33:15 2006
Nov  6 17:33:15 t21305    name=jochemv[] map=/etc/auto_indirect opts= 
path=/auto/home direct=0
Nov  6 17:33:15 t21305  LOOKUP REPLY    : status=0
Nov  6 17:33:15 t1      MOUNT REQUEST:   Mon Nov  6 17:33:15 2006
Nov  6 17:33:15 t1        name=jochemv[] map=/etc/auto_indirect opts= 
path=/auto/home direct=0
Nov  6 17:33:15 t1        PUSH /etc/auto_indirect
Nov  6 17:33:15 t1        POP /etc/auto_indirect
Nov  6 17:33:15 t1        mapline:      ruby:/home:jochemv
Nov  6 17:33:15 t1        do_mount1:
Nov  6 17:33:15 t1        (nfs,nfs)     /auto/home/jochemv
               -
               ruby:/home/jochemv      penalty=0
Nov  6 17:33:15 t1        nfsmount: input: ruby[other]
Nov  6 17:33:15 t1        nfsmount: standard mount on /auto/home/jochemv :
Nov  6 17:33:15 t1          ruby:/home/jochemv
Nov  6 17:33:15 t1        nfsmount: v3=1[0],v2=0[0] => v3.
Nov  6 17:33:15 t1        nfsmount: Get mount version: request vers=3 min=3
Nov  6 17:33:15 t1        nfsmount: mount version=3
Nov  6 17:33:15 t1      Port numbers are 782, 782
Nov  6 17:33:15 t1      Port match
Nov  6 17:33:15 t1        mount ruby:/home/jochemv /auto/home/jochemv ()
Nov  6 17:33:15 t1        nfs_args: ruby, , 0x2004060, 0, 0, 0, 0, 0, 0, 0, 0,
Nov  6 17:33:15 t1        args_temp: ruby, , 0x3004060, 0, 0, 0, 0, 0, 0, 0, 
0, ruby:/home/jochemv
Nov  6 17:33:15 t1        mount ruby:/home/jochemv dev=3f00000a rdev=0 OK
Nov  6 17:33:15 t1      MOUNT REPLY    : status=0, AUTOFS_DONE


mounting nonexisting blabla
============================
No entry in syslog.

These are the messages in /var/adm/automount.log (kill -SIGUSR2 <automountPID>)


Nov  6 17:33:40 t21306  LOOKUP REQUEST: Mon Nov  6 17:33:40 2006
Nov  6 17:33:40 t21306    name=blabla[] map=/etc/auto_indirect opts= 
path=/auto/home direct=0
Nov  6 17:33:40 t21306    PUSH /etc/auto_indirect
Nov  6 17:33:40 t21306    POP /etc/auto_indirect
Nov  6 17:33:40 t21306    do_lookup1: action=2 wildcard=FALSE error=2
Nov  6 17:33:40 t21306  LOOKUP REPLY    : status=2
========================================================================= 
Comment 7 Jeffrey Moyer 2007-01-23 14:12:21 EST
Created attachment 146338 [details]
Patch to report failed lookups
Comment 8 Jeffrey Moyer 2007-01-23 14:26:22 EST
With this patch, failed lookups will result in log entries of the form:

Jan 23 14:10:12 dhcp-10-12-34-199 automount[10191]: attempting to mount entry
/repl/foojooboo
Jan 23 14:10:12 dhcp-10-12-34-199 automount[10846]: lookup(file): key
"foojooboo" not found in map.
Comment 15 Ronald Pacheco 2007-02-09 14:55:24 EST
Terry,
What version of RHEL do you want this addressed in?  You have RHEL 5.1 feature
trackers against this request, but it's a RHEL4 issue.  Please advise/update
accordingly.
Comment 16 James Hofmeister 2007-02-09 15:00:31 EST
Hello Ronald, I work with Terry (HP) and he submitted this request on my 
behalf.  My customer is actually running RHEL-3-update-4.  We have created 
a "test" rpm and verified the solution works for them.  We are requesting this 
functionality be included in both RHEL-4 and RHEL-5 (and future).

Regards, 
  James Hofmeister  Hewlett Packard Linux Solutions Engineer
Comment 17 Ian Kent 2007-02-10 01:15:15 EST
(In reply to comment #16)
> Hello Ronald, I work with Terry (HP) and he submitted this request on my 
> behalf.  My customer is actually running RHEL-3-update-4.  We have created 
> a "test" rpm and verified the solution works for them.  We are requesting this 
> functionality be included in both RHEL-4 and RHEL-5 (and future).
> 
> Regards, 
>   James Hofmeister  Hewlett Packard Linux Solutions Engineer
> 

I have to dissagree with using the info log level, as has been
done in the customers patch, as this is contrary to the way in
which the logging is meant to be used in autofs.

The basic problem is that if this or other information like
it is logged at syslog severity info then the logs can easily
become very busy without any benifit, causing others to complain
about it.

So, if anything, the mount fail messages should be changed to
log at verbose level.

Ian
Comment 18 Ronald Pacheco 2007-02-10 07:31:29 EST
Based on comments 16 and 17, I am cloning this request for RHEL5.1.
Comment 21 Jeffrey Moyer 2007-02-20 13:09:23 EST
*** Bug 229374 has been marked as a duplicate of this bug. ***
Comment 23 RHEL Product and Program Management 2007-05-09 04:38:58 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 27 John Poelstra 2007-08-29 00:21:58 EDT
A fix for this issue should have been included in the packages contained in the
RHEL4.6 Beta released on RHN (also available at partners.redhat.com).  

Requested action: Please verify that your issue is fixed to ensure that it is
included in this update release.

After you (Red Hat Partner) have verified that this issue has been addressed,
please perform the following:
1) Change the *status* of this bug to VERIFIED.
2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified)

If this issue is not fixed, please add a comment describing the most recent
symptoms of the problem you are having and change the status of the bug to FAILS_QA.

If you cannot access bugzilla, please reply with a message to Issue Tracker and
I will change the status for you.  If you need assistance accessing
ftp://partners.redhat.com, please contact your Partner Manager.
Comment 28 John Poelstra 2007-09-05 18:23:12 EDT
A fix for this issue should have been included in the packages contained in 
the RHEL4.6-Snapshot1 on partners.redhat.com.  

Requested action: Please verify that your issue is fixed to ensure that it is 
included in this update release.

After you (Red Hat Partner) have verified that this issue has been addressed, 
please perform the following:
1) Change the *status* of this bug to VERIFIED.
2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified)

If this issue is not fixed, please add a comment describing the most recent 
symptoms of the problem you are having and change the status of the bug to 
FAILS_QA.

If you cannot access bugzilla, please reply with a message about your test 
results to Issue Tracker.  If you need assistance accessing 
ftp://partners.redhat.com, please contact your Partner Manager.
Comment 31 errata-xmlrpc 2007-11-15 11:02:04 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0734.html

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