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. 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 -- 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/20160404/774fa244/attachment.sig>
Edward Tomasz Napierała
2016-Apr-05 11:58 UTC
Interaction between make & autofs/automountd
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 :-)