|Summary:||After autofs service is restarted, "problem reading master map, maximum wait exceeded" message is logged.|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Gaurav <gkulkarn>|
|Component:||autofs||Assignee:||Ian Kent <ikent>|
|Status:||CLOSED WONTFIX||QA Contact:||xiaoli feng <xifeng>|
|Version:||6.9||CC:||cww, eguan, ikent, kladiv, xifeng|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2017-08-15 21:33:12 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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: problem reading master map, maximum wait exceeded Mar 30 09:14:27 hostname automount: 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: problem reading master map, maximum wait exceeded Mar 30 09:14:27 hostname automount: 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