Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice!sun-spots-request
From: chris@com50.c2s.mn.org (Chris Johnson)
Newsgroups: comp.sys.sun
Subject: Re: /bin/login hangs if an NFS server down?
Keywords: Miscellaneous
Message-ID: <340@brchh104.bnr.ca>
Date: 20 Nov 90 18:00:01 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 17
Approved: Sun-Spots@rice.edu
X-Original-Date: Wed, 31 Oct 90 21:50:59 GMT
X-Refs:  Original: v9n337, Replies: v9n339
X-Sun-Spots-Digest: Volume 9, Issue 365, message 9
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

In article <1990Oct26.221451.18656@rice.edu> auspex!guy@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.

So, if you want to get around this hang, and are not running quotas,
you've got a few choices.  Instead of mounting with the noquota option
(since it's not a default, you'll have to remember it all the time for
manual mounts), we here instead just replaced /usr/ucb/quota with a link
to /usr/bin/true.  Makes things run a lot quicker at bootup and login,
since the quota check turns into a very short program call.