Thanks for your reply On Thu, Jun 15, 2017 at 06:45:00PM +0800, Ian Kent wrote: > On Thu, 2017-06-15 at 17:52 +0800, Ian Kent wrote: > > On Thu, 2017-06-15 at 12:19 +1000, Vincent McIntyre wrote: > > > Hello > > > > > > I can't see this in the manpages or README.replicated-server, > > > perhaps I can provide a patch... > > > > > > I have this setup: > > > > > > $ grep autofs /etc/nsswitch.conf > > > autofs: files nis > > > > > > $ cat /etc/auto.master > > > /nfs auto.nfs -rw,hard,intr,vers=3 > > > $ ypcat -k auto.nfs > > > foo -ro,hard boxa,boxb:/export/foo > > > > > > > > > Question: > > > > > > If boxa has the NFS server running (so autofs ping works) > > > but does not export /export/foo, > > > what is the expected behaviour? > > > > I haven't looked, so just I'll say what I think should happen. > > > > > > > > boxa and boxb are in different subnets, the client is in > > > the same subnet as boxa. > > > > If the network proximity code is working properly boxb probably > > won't make it to the list of servers to try because it should > > look like it's further away. That makes some kind of sense, but see below. > > > > > > > > What I am seeing is that the automount fails completely > > > upon trying boxa. boxb is never tried (no request logged on boxb). > > > Looking at the autofs debug log, I can see > > > get_nfs_info called for boxa, twice in fact. > > > For boxb, only get_supported_ver_and_cost is called, > > > after which the daemon tries to mount the share from boxa. > > > > That's likely expected as I'm pretty sure I construct the list > > of servers that have the selected characteristics including > > proximity. > > > > For proximity it will check network address against local > > interfaces to work that out so you probably shouldn't see an NFS > > ping at all as that's used to establish best response amongst > > the list of selected servers. > > > > I'd need to have a look at the code. > > > > > > > > > > > What I was hoping to see is that the client also tries boxb > > > before giving up. > > > > > > I tried fiddling with: > > > the order (boxb,boxa:/export/foo) > > > weights (boxb(3),boxa:/export/foo), > > > but none of this made any difference. > > > > If I'm right then boxb won't get onto the list of servers to try > > so there's probably not much you can do about it, (again if I am > > right) possibly it should change to include the further away > > servers .... that might not be a straight forward change ... > > Actually it looks more like boxb should be added to the end of the > list of servers to try. > > I see a bug in there but I don't think it's triggering. It's more > likely there's been a problem connecting to boxb for some reason. > > The debug log might be useful but I'd probably still need to add > some more debug log messages to work out what's going on. > Connection to boxb was working fine, I did a manual mount to check. I was able to get the behaviour I wanted by adding --use-weight-only (ie -w in auto.master) and not specifying any weights in auto.nfs. Is it correct to say that --use-weight-only turns off all the proximity heuristics ? I think not because autofs.master says ...If no server weights are given then each available server will be tried in the order listed, within proximity. But that manpage never mentions proximity anywhere else, so perhaps it would be helpful to refer the reader to "the package's README files" ? Going back over README.replicated-servers, it does not say anything that suggests hosts are _left out_ of the priority-ordered list. So perhaps there is a little buglet in there somewhere. Vince -- To unsubscribe from this list: send the line "unsubscribe autofs" in
