Hide Forgot
Description of problem: The recent upgrade of autofs broke mounting of home directories in my case. I thought it might be a duplicate of BZ1395641 but I can reproduce a bug even with autofs-5.0.5-127 Version-Release number of selected component (if applicable): autofs-5.0.5-127.el6.x86_64 autofs-5.0.5-126.el6.x86_64 How reproducible: Deterministic Steps to Reproduce: 1. the modification of configuration is quite simple cat >> /etc/auto.master <<EOF # NFS exported home directories /home /etc/auto.home EOF cat >> /etc/auto.home <<EOF * -rw,intr,vers=3 rhev-01.eng.example.com:/mnt/dev-lab/home/& EOF 2. service autofs restart 3. try to list content of some user directory. ls /home/user Actual results: ls: cannot access /home/user: No such file or directory Expected results: User home directory is mounted. Additional info: My workaround is to comment out "+auto.master" from /etc/auto.master diff --git a/auto.master b/auto.master index 41871f0..39a83e9 100644 --- a/auto.master +++ b/auto.master @@ -20,6 +20,6 @@ # same will not be seen as the first read key seen takes # precedence. # -+auto.master +#+auto.master # NFS exported home directories /home /etc/auto.home Then user directory is properly mounted.
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.