Interaction between make & autofs/automountd

[David Wolfskill]

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				david at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20160405/02b0b5f6/attachment.sig>