/bin/login hangs if an NFS server down?

[John Ruckstuhl]

In article <1990Oct26.221451.18656 at rice.edu> auspex!guy at uunet.uu.net (Guy Harris) writes:
>>|Does anybody know what the heck /bin/login is doing in that child process
>>|that takes 1'16" to terminate?  Is it secretly doing a df?
>
>You may not be running quotas, but unless the client has done all its NFS
>mounting with the "noquota" option, "/usr/ucb/quota", which is run by
>"/usr/bin/login", will still try to talk to the quota daemons on all the
>servers for file systems the client has mounted in order to find out
>whether the user logging in is over quota or not.  If the server is down,
>this will time out, and take a while to do so.

Our SPARCstation 1+'s (SunOS 4.1) nfs-mount auxilliary filesystems, which
consist of archives of various flavors and applications maintained by the
College's computer support department).  When the computer support
department's SPARCstation is unreachable (network failure or actually
down), all of our SPARCstation 1+'s hang (until the remote computer is
again reachable).

We would like to avoid this disruption (since the data on the remote
computer is not necessary for our continued operation).

I would think from reading fstab(5), that a "bg" OR a "soft" option in the
mounting of the remote filesystems would avoid this hanging, but someone
else explains to me that "these options refer to the initial attempt to
mount, i.e. at boot-time, and are irrelevant to the interrupted
availability of the remote file-system".

"Further, there is no way to avoid your computers' hanging when the
already nfs-mounted remote filesystem becomes unavailable".

Please confirm this or suggest a workaround.

I follow-up to Guy Harris' article because it suggests (to me, at least)
that my problem may be related to quota accounting. 

John R Ruckstuhl, Jr
University of Florida		ruck at cis.ufl.edu, uflorida!ruck