Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: woodstock!mike@uunet.uu.net (Mike Ubell)
Newsgroups: comp.sys.sun
Subject: Re: Help with automounter
Keywords: Miscellaneous
Message-ID: <1100@brchh104.bnr.ca>
Date: 8 Jan 91 22:07:30 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 31
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v10n3
X-Sun-Spots-Digest: Volume 10, Issue 11, message 11
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

In article <1021@brchh104.bnr.ca> you write:

>We are using the automounter extensively in our campus. We just upgraded
>to SunOS 4.1.1 and find that every once in a while the automounter gets
>stuck at a non-interruptible wait. Presumably it is waiting for some NFS
>server to respond. I have noticed the load going up to around 36 with
>nothing running.
>
>What I would like to do is have it fail if the NFS server does not respond
>in a second or two.
>
>I thought the -soft option did this, but apparently, it does not. I tried
>putting in a retry=20 option (default is 10000), but it seems to be
>ignored when -soft is also specified. 
>
>What mount options should I use in the automounter's NIS maps in order to
>have it fail when a very slow NFS server does not answer?


This shounds like you are automounting /usr/share/lib/zoneinfo (or one of
its parents).  Automount runs fine until it must print an error, like when
a server does not respond, at which point it MUST (why?) timestamp its
messages and therefore acess the zoneinfo.  This cuases it to wait for
itself.  Most everything else will eventually run into automount and wait
in a state that is counted as part of the load (I have a suspicion that
things just acessing sockets get hung as well but have not done any
conclusive experiments).

Sun says "dont auto mount /usr/share" (why call it SHARE?).  We automount
/usr/share/man /usr/share/src and /usr/share/bin (a locally added
directory) and distribute /usr/share/lib.