RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1438699 - After autofs service is restarted, "problem reading master map, maximum wait exceeded" message is logged.
Summary: After autofs service is restarted, "problem reading master map, maximum wait ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: autofs
Version: 6.9
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Ian Kent
QA Contact: xiaoli feng
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-04 08:42 UTC by Gaurav
Modified: 2021-12-10 14:59 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-15 21:33:12 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Gaurav 2017-04-04 08:42:22 UTC 
Description of problem:

When "autofs" service is restarted, below logs are seen :

Mar 30 09:14:27 hostname automount[3009]: problem reading master map, maximum wait exceeded
Mar 30 09:14:27 hostname automount[3009]: automount: warning: could not read at least one map source after waiting, continuing ...

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

autofs-5.0.5-132.el6.x86_64

How reproducible:

Whenever autofs is restarted, these logs are logged. 

Actual results:

I see logs :
Mar 30 09:14:27 hostname automount[3009]: problem reading master map, maximum wait exceeded
Mar 30 09:14:27 hostname automount[3009]: automount: warning: could not read at least one map source after waiting, continuing ...

Expected results:

These logs should not appear.

Additional info:

If "+auto.master" entry in /etc/auto.master is commented, the logs are not seen.
Comment 2 Ian Kent 2017-04-04 11:40:30 UTC 
This looks like a side effect of a change that was included in
RHEL-6.9.

I was a bit concerned we might see this but it is an unavoidable
consequence of change that fixed a problem and some noise in the
log seemed reasonable since there was no other choice.

If in fact this is what I think it is then it is caused by not
setting the sources in /etc/nsswitch.conf properly.

Previously autofs was not sensitive to unconfigured map sources
listed in the automount entry of nsswitch.conf.

In order to implement a delay when map sources are not yet ready
to reply, such as when the network is up but the source is not
yet ready to answer queries, it's necessary to wait and retry
upon receiving an error. But if nsswitch.conf contains sources
that are unused (and not configured) an error is returned and
it can't be distinguished from a real error.

So the requirement now is that nsswitch.conf should be properly
configured and unused map sources removed.

The plus map inclusion line in /etc/auto.master will look for
master map entries in the map sources listed in the nsswitch.conf
automount line.

From the sosreport I see that the automount line in nsswitch.conf
contains "files nisplus" which is the default when it is installed
and I presume nisplus is not used or setup at this site.

The nsswitch.conf file is not owned by the autofs package and I
don't think it's wise to change the automount line on update but
perhaps it should be set to a sensible default by autofs on
initial install. 

This value in nsswitch.conf has been the default for a long time
and IMHO is not a sensible one.

But first lets confirm this is what is happening.
That can be done by removing nisplus from the automount line in
nsswitch.conf.
Comment 3 Gaurav 2017-04-06 05:10:35 UTC 
Thanks for your reply Ian. It worked.

On my test system, modified the entry in /etc/nsswitch.conf to :

      automount:  files 

The logs are not seen now.

Let me check with the customer as well.
Comment 4 Gaurav 2017-04-06 08:51:17 UTC 
It worked for the customer as well.

So are we planning to remove "nisplus" for automount in nsswitch.conf in upcoming autofs package ?
Comment 5 Ian Kent 2017-04-06 11:49:55 UTC 
(In reply to Gaurav from comment #4)
> It worked for the customer as well.
> 
> So are we planning to remove "nisplus" for automount in nsswitch.conf in
> upcoming autofs package ?

The reason it is still there is purely because the file isn't
owned by autofs.

It's owned by glibc.

As I said above I'd consider altering it at autofs initial
install but even then the automount line might have been
changed by users and autofs can't know if that's the case.
So it's difficult.

Ian
Comment 7 Claudio 2018-11-21 15:44:40 UTC 
Hello,
we still found this bug on:

autofs-5.0.5-133.el6_9.x86_64

and automounts (NFS) seems not working.

Our workaround is to change /etc/nsswitch.conf to:
  
  automount:  files

Why bug has flagged WONFTIX?

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