On 0404T0549, David Wolfskill wrote: > 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.) > > > > The machines that use autofs do so by using symlinks and the existing > > maps; e.g.: > > > > 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/howland/c/ports > > ... > > > > 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. > > > > For most purposes, including: > > * svn update > > * cd to a port directory > > * Updating files in distfiles > > * reading arbitrary files in the tree > > > > this works well, and there's no indication of any problems or issues. > > > > I recently noticed, thiough, that running "portmaster -aF" generates a > > large number of messages. > > > > I was able to narrow this down to portmaster's invocation of (e.g.) > > * cd /usr/ports/sysutils/dmidecode > > * make -V PKGNAME > > > > 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: > > > > albert(10.2-S)[4] dirs; date; make -V PKGNAME; date > > /usr/ports/sysutils/dmidecode > > Mon Jan 11 07:26:45 PST 2016 > > dmidecode-3.0 > > Mon Jan 11 07:26:47 PST 2016 > > albert(10.2-S)[5] > > > > Jan 11 15:26:45 albert automountd[13912]: "/etc/autofs/special_hosts > > share", 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 > > share", 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 > > share", 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", 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? > 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 :-) _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
