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: 2018-11-22 04:13 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


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.