Kennedy_J_Lemke@princeton.edu (Kennedy Lemke) (06/05/91)
[I posted this to comp.sys.admin originally a couple weeks ago but got no responses. I hope someone can help; if you're interested, please read the whole article before replying. Thanks -- kjl]. Often times (it has been difficult to determine the exact circumstances), the "quota" program seems to take interminably long to execute--in fact, up to several minutes. And since quota is built into the login program (rightfully so, in my opinion), it can thus take this long to log into our cycle server machine. For our site, the use of the quota command requires a call to rpc.rquotad on our NFS server, since home file systems are all nfs-mounted. I've trace(1)'d the rpc.rquotad command and haven't seen anything unusual, except that the execution seems slow (and that rpc.rquotad seems to be doing much more work that I think it needs to do). Obviously when it takes several minutes, or even more than about 30 or 60 seconds, to log into our cycle server, our users complain. To solve this problem, I replaced /usr/ucb/quota with a shell script that does an exit 0 when called with no arguments, or executes "quota.exe -v" when called with a "-v" flag (quota.exe is the sparc executable). And logging into the cycle server then becomes very fast. But then after a couple days, I again start getting complaints from our users that now they have gone over their quota and hadn't been notified of this fact upon login. So I change the programs back again (move the real quota back into place), and all is fine until logging in becomes interminably slow again. And so on, and so on. Surely others have experienced the same thing. I'd like to be enlightened on two things: first, is the culprit of this activity really an inefficient rpc.rquotad? Second, what is the best solution to this problem? Installing a login that doesn't call "quota" is not an option. Is there a more efficient rpc.rquotad around, or do I need to write my own? Or should I simply leave the shell script in place and concentrate on educating my users (3700 of them). Please give me suggestions, and please respond via email since I can't read this group as often as I'd like to. I'll summarize if there is interest. Thanks. Kennedy Lemke Systems Programmer CIT--87 Prospect Princeton University Princeton, New Jersey 08544 Work Phone: (609) 258-6033 Internet: lemke@Princeton.EDU Fax Phone: (609) 258-3943 uucp: ...rutgers!princeton!lemke Home Phone: (609) 275-7298 Bitnet: LEMKE@PUCC.BITNET