On Tue, Apr 05, 2016 at 01:58:40PM +0200, Edward Tomasz Napierała wrote: > ... > > > > automountd: waiting for request from the kernel > > automountd: not forking due to -d flag; will exit after servicing a single > > request > > automountd: got request 553: from map -hosts, path /net/, prefix "/net", > > key "share", options "nosuid,intr" > > automountd: parsing map "-hosts" > > automountd: executing "/etc/autofs/special_hosts share" as pid 12717 > > RPC: Unknown host > > showmount: can't do exports rpc > > automountd: "/etc/autofs/special_hosts share", pid 12717, terminated with > > exit status 1 > > automountd: failed to handle special map "-hosts" > > automountd: completing request 553 with error 5 > > > > > > So if the above is to be believed (which I certainly hope!), something > > is causing invocation of: > > > > /etc/autofs/special_hosts share > > > > which is problematic, as the argument (if any) to /etc/autofs/special_hosts > > is expected to be an entry name from /etc/hosts (or equivalent). > > > > In turn, this appears to be happening because something is invoking > > automountd with 'key "share"' -- and I'm not seeing what is doing that, > > but "make" seems to be one of the few(?) things that prompts this > > behavior. > > Hm, that's curious. Could you perhaps try to use ktrace(1) to see > if something is eg trying to access /net/share for some reason?
Aye -- and sure enough, it's smake(1). Here's what appears to be the relevant excerpt of the decoded ktrace, from an invocation of: ktrace -di make -C /usr/ports/sysutils/dmidecode -V PKGNAME ... 26861 make CALL close(0x3) 26861 make RET close 0 26861 make CALL stat(0x7fffffffce10,0x7fffffffcd98) 26861 make NAMI "/net/howland/c/ports/sysutils/dmidecode/obj.amd64" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffffffce10,0x7fffffffcd98) 26861 make NAMI "/net/howland/c/ports/sysutils/dmidecode/obj" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffffffe090,0x7fffffffcd98) 26861 make NAMI "/usr/obj/net/howland/c/ports/sysutils/dmidecode" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffffffc9f0,0x7fffffffc978) 26861 make NAMI "/net/howland/c/ports/sysutils/dmidecode/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffffffc9f0,0x7fffffffc978) 26861 make NAMI "/net/howland/c/ports/sysutils/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffffffc9f0,0x7fffffffc978) 26861 make NAMI "/net/howland/c/ports/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffffffc9f0,0x7fffffffc978) 26861 make NAMI "/net/howland/c/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffffffc9f0,0x7fffffffc978) 26861 make NAMI "/net/howland/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffffffc9f0,0x7fffffffc978) 26861 make NAMI "/net/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffffffc9f0,0x7fffffffc978) 26861 make NAMI "/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL open(0x6a229d,0x120004<O_NONBLOCK|O_DIRECTORY|O_CLOEXEC>,<unused>0x2f) 26861 make NAMI "/usr/share/mk" 26861 make RET open 3 26861 make CALL fstatfs(0x3,0x7fffffffcfd8) 26861 make RET fstatfs 0 .... I'm happy to provide the whole thing, if that would be useful. But the above looks as if make(1) is trying to find a local override for /usr/share/mk/ (which override I don't have). I suppose it's also possible that other programs might do similar things. > > In the mean time, I've now circumvented the issue in my case by > > creating a CNAME named "share" that points to the hostname of the > > NFS server. And sure enough, I no longer see the whines. > > > > While that does give a clear(er) indication of the nature of the > > problem, I suspect I'm setting myself up for "interesting modes of > > failure" when I need to refer to data that reside on a different > > NFS server (also accessed via the automounter). > > Well, the requests were already failing with EIO, it's just that > they fail much quicker now :-) And for slightly different reasons -- after all: albert(10.3-P)[14] df -h /net/share/c/ports Filesystem Size Used Avail Capacity Mounted on share:/c/ports 7.2T 5.0T 2.2T 69% /net/share/c/ports albert(10.3-P)[15] (Yeah, it's a hack.) Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Those who would murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature