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 [email protected]
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
