Date: Mon, 4 Apr 2016 05:49:15 -0700 From: David Wolfskill <david@catwhisker.org> To: stable@freebsd.org Subject: Re: Interaction between make & autofs/automountd Message-ID: <20160404124915.GM1232@albert.catwhisker.org> In-Reply-To: <20160111152849.GF1223@albert.catwhisker.org> References: <20160111152849.GF1223@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--lRF4gxo9Z9M++D0O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 11, 2016 at 07:28:49AM -0800, David Wolfskill wrote: > ... > A couple of the machines use autofs & automountd to make the ports tree > available on demand. (In the case of the 3rd, I manually mount it when > needed, but that's not at issue for this note, and I won't pursue that > further here.) >=20 > The machines that use autofs do so by using symlinks and the existing > maps; e.g.: >=20 > albert(10.2-S)[7] ls -lT /usr/ports > lrwxr-xr-x 1 root wheel 20 Dec 21 04:15:39 2010 /usr/ports -> /net/how= land/c/ports > ... >=20 > The contents of /etc/autofs are "vanilla" -- I have not changed > them. I did modify /etc/auto_master a bit, to remove the "nobrowse" > option for -net. >=20 > For most purposes, including: > * svn update > * cd to a port directory > * Updating files in distfiles > * reading arbitrary files in the tree >=20 > this works well, and there's no indication of any problems or issues. >=20 > I recently noticed, thiough, that running "portmaster -aF" generates a > large number of messages. >=20 > I was able to narrow this down to portmaster's invocation of (e.g.) > * cd /usr/ports/sysutils/dmidecode > * make -V PKGNAME >=20 > The "cd" seems OK; it's the "make -V PKGNAME" -- even if I invoke it by: > hand. It works, but at the expense of messages: >=20 > albert(10.2-S)[4] dirs; date; make -V PKGNAME; date > /usr/ports/sysutils/dmidecode=20 > Mon Jan 11 07:26:45 PST 2016 > dmidecode-3.0 > Mon Jan 11 07:26:47 PST 2016 > albert(10.2-S)[5]=20 >=20 > Jan 11 15:26:45 albert automountd[13912]: "/etc/autofs/special_hosts shar= e", pid 13913, terminated with exit status 1 > Jan 11 15:26:45 albert automountd[13912]: failed to handle special map "-= hosts" > Jan 11 15:26:45 albert kernel: WARNING: autofs_trigger_one: request for /= net/ completed with error 5 > Jan 11 15:26:46 albert automountd[13915]: "/etc/autofs/special_hosts shar= e", pid 13916, terminated with exit status 1 > Jan 11 15:26:46 albert automountd[13915]: failed to handle special map "-= hosts" > Jan 11 15:26:46 albert kernel: WARNING: autofs_trigger_one: request for /= net/ completed with error 5 > Jan 11 15:26:47 albert automountd[13918]: "/etc/autofs/special_hosts shar= e", pid 13919, terminated with exit status 1 > Jan 11 15:26:47 albert automountd[13918]: failed to handle special map "-= hosts" > Jan 11 15:26:47 albert kernel: WARNING: autofs_trigger_one: request for /= net/ completed with error 5 > ... The above got to bugging me enough that I looked into it again, and I stumbled across <https://forums.freebsd.org/threads/49012/>; in the process of trying figure out what was wrong. Using the clue there (of manually starting automountd in debugging mode), I find: 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", ke= y "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 e= xit 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. 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). 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. --lRF4gxo9Z9M++D0O Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXAmLLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4X5XwH/R6TqEnPit9wAlffFixHcYhS kHYZIov1DJG27ImJzgPaED23WILNL9fCssteTE5XGwx27A6SRulDYS/Z7eSAbKQj 3nwXmQ2Pt4DHIDPjBSTxNFAaCIgJ0LROdRT0l7KPiDDroNUK2jF+eMniLeE6ZlbL LaUWQsIR9NrV824lbM+qpUPSDIr2rY5NfS9SxXL3cvpMJmLatw7iwnvfmJWmLZ1C Uxg9vBiYRkcf1nqQgZG/8m1wfwaFfYuqDThkQotu96xcIKwZ3VP0KDmeYDTwbCMQ rV4ntGn+iyLJTynNWk9fzRk2FbNZlKp2DKWSTbWViEQKd4SRnDczSo+lTS1seQ8= =6pYB -----END PGP SIGNATURE----- --lRF4gxo9Z9M++D0O--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160404124915.GM1232>