Date: Tue, 5 Apr 2016 05:30:12 -0700 From: David Wolfskill <david@catwhisker.org> To: stable@freebsd.org Subject: Re: Interaction between make & autofs/automountd Message-ID: <20160405123012.GY1232@albert.catwhisker.org> In-Reply-To: <20160405115840.GA47120@brick.home> References: <20160111152849.GF1223@albert.catwhisker.org> <20160404124915.GM1232@albert.catwhisker.org> <20160405115840.GA47120@brick.home>
next in thread | previous in thread | raw e-mail | index | archive | help
--Qesg98+uAFykT7J8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 05, 2016 at 01:58:40PM +0200, Edward Tomasz Napiera=C5=82a wrot= e: > ... > >=20 > > automountd: waiting for request from the kernel > > automountd: not forking due to -d flag; will exit after servicing a sin= gle 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 wi= th exit status 1 > > automountd: failed to handle special map "-hosts" > > automountd: completing request 553 with error 5 > >=20 > >=20 > > So if the above is to be believed (which I certainly hope!), something > > is causing invocation of: > >=20 > > /etc/autofs/special_hosts share > >=20 > > which is problematic, as the argument (if any) to /etc/autofs/special_h= osts > > is expected to be an entry name from /etc/hosts (or equivalent). > >=20 > > 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. >=20 > 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 =2E.. 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_CLOEX= EC>,<unused>0x2f) 26861 make NAMI "/usr/share/mk" 26861 make RET open 3 26861 make CALL fstatfs(0x3,0x7fffffffcfd8) 26861 make RET fstatfs 0 =2E... 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. > >=20 > > 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). >=20 > 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]=20 (Yeah, it's a hack.) Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Qesg98+uAFykT7J8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXA6/UXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XJdMIAK+OnRZ9NPcGk5qua/ivCMuY E7A4KGwt9mRxrrvLedvbS4MLuWTQMzisJZicFh2bvb+QUYzv93iqFlTCxEog4pIz QuWIDfVhsUb+RkYVWawNRG6yNvY2DWyX4xI0IouOhWm7B/5/YpPMXQm6OaR4SghL rYn1J3yxAlA6ZpYNiCihAM37pD54WSOabUysIjQ4mA1yvFgs04mYj4tnNymtr6ZI hIDgeimU/yVtw6x81b8RZWF/vNE+4tEgAbQSvNGYU3+UGjh6PoYlG0bvLNQm+IZK pBauJRbLJ4/mOlmHjc/WBL4/9LmtKzXQFHAjznP3Zw6gUXHXFgD6cn9+oCAhtG4= =3oCj -----END PGP SIGNATURE----- --Qesg98+uAFykT7J8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160405123012.GY1232>