Bug 1397431

Output without workaround:

[root@vm-121 etc]# automount -v -f --pid-file /var/run/autofs.pid
Starting automounter version 5.0.5-127.el6, master map auto.master
using kernel protocol version 5.02
lookup(file): failed to read included master map auto.master
main:2451: automount: failed to read master map, will retry!
ignoring duplicate indirect mount /misc
ignoring duplicate indirect mount /net
lookup(file): failed to read included master map auto.master
ignoring duplicate indirect mount /home
lookup(file): failed to read included master map auto.master
lookup(file): failed to read included master map auto.master
lookup(file): failed to read included master map auto.master
lookup(file): failed to read included master map auto.master
problem reading master map, maximum wait exceeded
automount: warning: could not read at least one map source after waiting, continuing ...
lookup(file): failed to read included master map auto.master
mounted indirect on /misc with timeout 300, freq 75 seconds
mounted indirect on /net with timeout 300, freq 75 seconds
mounted indirect on /home with timeout 300, freq 75 seconds

Output with workaround "+autofs.master"
[root@vm-121 etc]# automount -v -f --pid-file /var/run/autofs.pid
Starting automounter version 5.0.5-127.el6, master map auto.master
using kernel protocol version 5.02
mounted indirect on /misc with timeout 300, freq 75 seconds
mounted indirect on /net with timeout 300, freq 75 seconds
mounted indirect on /home with timeout 300, freq 75 seconds

[root@vm-121 etc]# grep auto /etc/nsswitch.conf 
automount:  files nisplus

(In reply to Lukas Slebodnik from comment #3)
> Actually, it does not work just for the 1st time
> So it's a little improvement comparing to 5.0.5-126; but still a tiny
> regression
> comparing to 5.0.5-125

It sounds like the 10 second delay that occurs when an unconfigured
source, nisplus in this case, is present in /etc/nssswitch.conf is
causing autofs to not be ready soon enough.

The problem is that an unconfigured source looks just like a network
not ready condition so autofs waits for 10 seconds before continuing
anyway.

There are two senarios to check before deciding what to do about
the change that's causing this.

Check that if you wait a while, 15 seconds should be enough, that
you can access home directories as expected.

Check what happens if you set "master_wait = 0" in /etc/autofs.conf
and see if autofs then behaves as before.

I'll re-check the logic here and make sure that a setting of
"master_wait = 0" behaves as before the change.

That may be needed for this change along with advice to remove
any unconfigured sources from /etc/nsswitch.conf before using
the configuration option.

Ian

(In reply to Ian Kent from comment #4)
> (In reply to Lukas Slebodnik from comment #3)
> > Actually, it does not work just for the 1st time
> > So it's a little improvement comparing to 5.0.5-126; but still a tiny
> > regression
> > comparing to 5.0.5-125
> 
> It sounds like the 10 second delay that occurs when an unconfigured
> source, nisplus in this case, is present in /etc/nssswitch.conf is
> causing autofs to not be ready soon enough.

Ha, I think I'm guilty of doing what the other services do to
cause this problem.

I'm trying to read the master map and if it gets a fail I continue
and retry reading the master map "after" daemonizing and returning.

So autofs essentially claims it's up and running when it's actually
waiting for the master map read.

So I can either do the retry before returning at startup or mount
what I have if the map entry list isn't empty and continue to try
and read the master map for the configured timeout in a manner
similar to HUP signal processing.

I'll need to think about this a bit more.

Ian

(In reply to Ian Kent from comment #5)
> (In reply to Ian Kent from comment #4)
> > (In reply to Lukas Slebodnik from comment #3)
> > > Actually, it does not work just for the 1st time
> > > So it's a little improvement comparing to 5.0.5-126; but still a tiny
> > > regression
> > > comparing to 5.0.5-125
> > 
> > It sounds like the 10 second delay that occurs when an unconfigured
> > source, nisplus in this case, is present in /etc/nssswitch.conf is
> > causing autofs to not be ready soon enough.
> 
> Ha, I think I'm guilty of doing what the other services do to
> cause this problem.
> 
> I'm trying to read the master map and if it gets a fail I continue
> and retry reading the master map "after" daemonizing and returning.
> 
> So autofs essentially claims it's up and running when it's actually
> waiting for the master map read.
> 
> So I can either do the retry before returning at startup or mount
> what I have if the map entry list isn't empty and continue to try
> and read the master map for the configured timeout in a manner
> similar to HUP signal processing.
> 
> I'll need to think about this a bit more.
> 
> Ian

"automount:  files nisplus" is a default line in /etc/nsswitch.conf.
I would assume that it should work with default; expeciali if it worked with 5.0.5-125.

(In reply to Lukas Slebodnik from comment #6)
> (In reply to Ian Kent from comment #5)
> > (In reply to Ian Kent from comment #4)
> > > (In reply to Lukas Slebodnik from comment #3)
> > > > Actually, it does not work just for the 1st time
> > > > So it's a little improvement comparing to 5.0.5-126; but still a tiny
> > > > regression
> > > > comparing to 5.0.5-125
> > > 
> > > It sounds like the 10 second delay that occurs when an unconfigured
> > > source, nisplus in this case, is present in /etc/nssswitch.conf is
> > > causing autofs to not be ready soon enough.
> > 
> > Ha, I think I'm guilty of doing what the other services do to
> > cause this problem.
> > 
> > I'm trying to read the master map and if it gets a fail I continue
> > and retry reading the master map "after" daemonizing and returning.
> > 
> > So autofs essentially claims it's up and running when it's actually
> > waiting for the master map read.
> > 
> > So I can either do the retry before returning at startup or mount
> > what I have if the map entry list isn't empty and continue to try
> > and read the master map for the configured timeout in a manner
> > similar to HUP signal processing.
> > 
> > I'll need to think about this a bit more.
> > 
> > Ian
> 
> "automount:  files nisplus" is a default line in /etc/nsswitch.conf.
> I would assume that it should work with default; expeciali if it worked with
> 5.0.5-125.

Sure, and that's what needs to happen, but there's no way to tell
if the fail is due to a source that's not configured or if there's
a transient network problem.

Moving the retry up before returning will slow the startup down a
bit but autofs won't return until it has mounted what it's seen so
that should make it behave as it did before, all be it a bit slower.

Not really sure if that delay is ok though, so changing it to continue
trying to read the master map after startup using a method similar to
HUP signal processing would allow it to startup without the delay.

The gotcha with that is what if there really is a transient network
problem (like the NIS client returned before having established a
connection to the NIS server, the original problem) and the map
that couldn't be read holds important mounts ....

Ian

(In reply to Ian Kent from comment #7)
> (In reply to Lukas Slebodnik from comment #6)
> > "automount:  files nisplus" is a default line in /etc/nsswitch.conf.
> > I would assume that it should work with default; expeciali if it worked with
> > 5.0.5-125.
> 
> Sure, and that's what needs to happen, but there's no way to tell
> if the fail is due to a source that's not configured or if there's
> a transient network problem.
> 
> Moving the retry up before returning will slow the startup down a
> bit but autofs won't return until it has mounted what it's seen so
> that should make it behave as it did before, all be it a bit slower.
> 
> Not really sure if that delay is ok though, so changing it to continue
> trying to read the master map after startup using a method similar to
> HUP signal processing would allow it to startup without the delay.
> 
> The gotcha with that is what if there really is a transient network
> problem (like the NIS client returned before having established a
> connection to the NIS server, the original problem) and the map
> that couldn't be read holds important mounts ....
> 
I am little bit confused.
Do you plan to do some change in autofs?
or would you prefer just document this new issue and recommend "master_wait = 0".

Do I need to test something or was provided machine enough for testing.?

Can you try using revision 128 please.

It's located at:
http://people.redhat.com/ikent/autofs-5.0.5-128.el6/

Ian

(In reply to Ian Kent from comment #11)
> Can you try using revision 128 please.
> 
> It's located at:
> http://people.redhat.com/ikent/autofs-5.0.5-128.el6/
> 
> Ian

Works like a charm. Thank you very much.
I hope customer will appreciate upgrade without issues.

(In reply to Lukas Slebodnik from comment #12)
> (In reply to Ian Kent from comment #11)
> > Can you try using revision 128 please.
> > 
> > It's located at:
> > http://people.redhat.com/ikent/autofs-5.0.5-128.el6/
> > 
> > Ian
> 
> Works like a charm. Thank you very much.
> I hope customer will appreciate upgrade without issues.

That's great.

I did find something else that needed changing so if you get
time please also check revision 129, it should appear to work
the same revision 128 but just in case ....

Find it at:
http://people.redhat.com/~ikent/autofs-5.0.5-129.el6/

Ian

(In reply to Ian Kent from comment #13)
> (In reply to Lukas Slebodnik from comment #12)
> > (In reply to Ian Kent from comment #11)
> > > Can you try using revision 128 please.
> > > 
> > > It's located at:
> > > http://people.redhat.com/ikent/autofs-5.0.5-128.el6/
> > > 
> > > Ian
> > 
> > Works like a charm. Thank you very much.
> > I hope customer will appreciate upgrade without issues.
> 
> That's great.
> 
> I did find something else that needed changing so if you get
> time please also check revision 129, it should appear to work
> the same revision 128 but just in case ....
> 
> Find it at:
> http://people.redhat.com/~ikent/autofs-5.0.5-129.el6/
> 
> Ian

This version works as well.