Thanks for all the responses! The simple answer is:
cd /usr/ucb
mv quota quota.orig
ln -s /bin/true quota
Other suggestions:
Use noquota in /etc/fstab
Diable rquotad in inetd.conf
Use .hushlogin in $HOME
Interesting info:
----------
Date: Thu, 16 Jul 92 16:15:39 CDT
From: pwright@spiff.msfc.nasa.gov (Patrick D. Wright)
To: ken@visix.com
Subject: Re: Login inexplicably hangs on /usr/ucb/quota
Ken,
I had your problem once and my solution is the same as yours. As I
guess you figured out, login runs the quota program. When a NFS
mounted file system goes down it still shows up as mounted so quota
waits for a very long time for a reply ( ~5 min. on our machines). If
you had rebooted the server you would not have had the problem because
the NFS file systems (being down) would not have been mounted and
quota would not check them. My guess is that this is the first time
that this situation has occured with your new system.
For me the solution was not too difficult because I did not have many
machines to make the changes on. From the tone of your question I
gather that is not your case. There may be some options to decrease
the amount of time that an NFS command waits before aborting but I
think you are still back to making many more changes than you want to
make.
Pat
----------
Date: Thu, 16 Jul 92 10:59:21 PDT
From: guy@auspex.com (Guy Harris)
To: ken@visix.com
Subject: Re: Login inexplicably hangs on /usr/ucb/quota
> PID TT STAT TIME COMMAND
> 7636 co IW 0:00 login
> 7637 co IW 0:00 /usr/ucb/quota
>
>We're not running with quota's so I was suprised to see login hanging
>on it.
It doesn't matter. "login" will *always* run "quota", which will try to
contact the "remote quota" RPC server for *all* NFS-mounted file
systems, to see if the user is over quota on them, except for...
>Finally, we modified our fstab so that all of our NFS mounted
>file systems (including the home directory one) were all mounted
>rw,bg,noquota which seemed to fix the problem on one machine.
...those mounted with "noquota".
>I'm not
>looking forward to walking around to all our nodes and editing their
>fstab's. Can anyone suggest why this problem would suddenly pop up?
It'd pop up if the "remote quota" server "rpc.rquotad" were, for some
reason, not responding - e.g., had dropped core.
----------
Date: Thu, 16 Jul 92 07:45:42 PDT
From: jumper@spf.trw.com (Greg Jumper)
To: ken@visix.com
Subject: Re: Login inexplicably hangs on /usr/ucb/quota
You're right that NFS timeouts cause the hangs. There are several things you
can do to eliminate the problem:
1) Move /usr/ucb/quota to /usr/ucb/quota.FCS and make a link from
/usr/bin/true to /usr/ucb/quota.
2) Use the "noquota" option, as you did. This is particularly
convenient if you use the automounter.
3) Disable "rquotad" by commenting out its line in /etc/inetd.conf.
Unfortunately, unless you use the automounter for all NFS filesystems, there
is no way around the fact that you will have to make changes on each machine
where you want quotas to be disabled.
--Greg Jumper TRW DSC Signal Processing Facility jumper@spf.trw.com
---------- Date: Thu, 16 Jul 92 14:52:14 +0200 From: cc_gucky@rcsun1.rcvie.co.at (Gerhard Holzer) To: ken@visix.com Subject: Re: Login inexplicably hangs on /usr/ucb/quota
A hint which is somewhere in Sun-Doku or software bulletins.
If you are NOT using quotas at all, you may
mv /usr/ucb/quota /usr/ucb/quota.orig ln -s /usr/bin/true /usr/ucb/quota
which speeds up login ;-)
BTW: Some time (OS releases) ago, they did the following in /etc/rc????
grep quota /etc/fstab && quotaon -a
which is not that intelligent, if you write ...,noquota,.. in the /etc/fstab
BUT they have learned .
Have they ??
Best regards Gucky
__ Internet: gucky@rcvie.co.at _________| |_____________ //-// _____ +-----------------------------------+ / Gerhard Holzer (Gucky) | \ | UUCP: ..!relay.EU.net!rcvie!gucky / +----------------------------------------+ | Tel : +(431) 39-16-21 / 163 + | Alcatel Austria - ELIN Research Center | | Fax : +(431) 39-14-52 / o \ \ | Ruthnergasse 1-7 | +-+---------------------/ -|- \-----+ | A-1210 Vienna - Austria - Europe | | | / \ +----------------------------------------+-+-+ - - ---------- Via: uk.ac.sheffield.dcs; Thu, 16 Jul 1992 13:37:12 +0100 Date: Thu, 16 Jul 92 13:37:14 BST From: Dave Mitchell <D.Mitchell@dcs.sheffield.ac.uk> To: ken@visix.com Subject: Re: Login inexplicably hangs on /usr/ucb/quota
> PID TT STAT TIME COMMAND > 7636 co IW 0:00 login > 7637 co IW 0:00 /usr/ucb/quota > >We're not running with quota's so I was suprised to see login hanging >on it. Finally, we modified our fstab so that all of our NFS mounted >file systems (including the home directory one) were all mounted >rw,bg,noquota which seemed to fix the problem on one machine. I'm not >looking forward to walking around to all our nodes and editing their >fstab's. Can anyone suggest why this problem would suddenly pop up? >The server machine hasn't been down for days.
Its difficult to give an authoritive answer, not knowing your network, but since quota has to contact *every* NFS server listed in fstab not protected by "noquota", there's a fair chance that one of those servers somewhere had temporarily gone v. slow / crashed/ rebooted, or someone had unplugged an ethernet cable somewhere, or... etc. The more hosts in fstab, the worse the problem becomes.
The reason why you got this problem even though "We're not running with quota's", is because although you may not have quotas enabled on the local machine or elsewhere, login doesnt know this, and so executes quota to check to see if you have a quota on any mounted patitions, inc. NFS ones.
I only know of two ways round this problem. The first (noquota option) you have already discovered, The second is for each user who doesnt want to "be hung" to have a .hushlogin file in thier home dir.
Dave.
* David Mitchell, Systems Administrator, email: D.Mitchell@dcs.shef.ac.uk * Dept. Computer Science, Sheffield Uni. phone: +44 742-768555 ext 5573 * PO Box 600, Sheffield S1 4DU, UK. fax: +44 742-780972 * * Standards (n). Battle insignia or tribal totems
---------- Thanks to everyone who replied: From: Dwight Ernest <dwight@hyphen.com> From: pwright@spiff.msfc.nasa.gov (Patrick D. Wright From: guy@auspex.com (Guy Harris) From: bwalker@auratek.com (Brad Walker) From: Mike Raffety <miker@sbcoc.com> From: Daniel Quinlan <danq@lemond.Colorado.EDU> From: VINCE@UCONNVM.UCONN.EDU From: jumper@spf.trw.com (Greg Jumper) From: ajs6143@eerpf001.boeing.com ( Andy J. Stefancik 206-234-3049 ) From: Charles <mcgrew@dartagnan.rutgers.edu> From: trinkle@cs.purdue.edu From: cc_gucky@rcsun1.rcvie.co.at (Gerhard Holzer) From: Dave Mitchell <D.Mitchell@dcs.sheffield.ac.uk> From: Piete.Brooks@cl.cam.ac.uk From: kalli!kevin@fourx.Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child}) From: Claus Assmann <ca@idefix.informatik.uni-kiel.dbp.de>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:45 CDT