Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!anchor!olson
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: itty bitty IRIX questions
Message-ID: <1991Jun2.191513.15569@odin.corp.sgi.com>
Date: 2 Jun 91 19:15:13 GMT
References: <9106020322.AA12664@crow.omni.co>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 57

In <9106020322.AA12664@crow.omni.co> rpaul@crow.UUCP (Rodian Paul) writes:

| Randy Carpenter asked:
| > |   2.) Why does ps(1) take so long every once in a while but then
| > |       has good response at other times.
| 
| Dave Olson answered:
| 
| > If you change /unix, or remove /tmp/.ps_data, the file gets re-created,
| > which takes a while.  After that ps runs faster.  Basicly it saves ps
| > having to grub through the kernel symbol table on each invocation.
| > 
| 
| Myself and others here have also noticed this problem. We don't dick
| with the kernels that often and to my knowledge nobody deliberatly 
| trashes /tmp/.ps_data. I'm afraid I don't think that the above 
| answer quite explains why the response is often so slow. The odd 
| thing is that the response problem doesn't seem tied to the load-average
| on the machine.

One other possiblity, if this happens all the time on a particular
machine is that you ran afoul of the date bug at one point, and
/unix has a mod time far in the future.  If so, the .ps_data file
will always be out of date.  I know of no other problems that cause
ps to *intermittently* take a much longer time to run on a particular
machine with a low load average.

(Actually, there IS one other possiblity.  If a lot of users
are YP/NIS users, then ps may be spending time waiting on yp to get
uid -> username translations, but this seems unlikely.

| Now for a naive question. I collect a lot of stuff from the net and the
| folders that I save via 'rn' often become quite large. At a later date, 
| when I try to run:
| 
| 	% Mail -f ~/News/Comp.foo
| 
| on a large file, I get the following response:
| 
| 	/tmp: No such file or directory

Mail is another 'old' program predating TMPDIR and tempnam().
Worse yet, there are no workarounds, as /tmp is hardcoded in
multiple places, and the error messages are less than informative.
I think a bug is already submitted on this; if not I'll create
one.  It isn't fixed in 4.0.  The only workaround is to make
/tmp be a symlink to /usr/tmp.

By the way, this problem is still in S5R3.2 mailx, and all the
4.3 Mail versions, including reno and tahoe.  This doesn't excuse
our not fixing it, but you will likely see the same problem on
other systems.
--

	Dave Olson

Life would be so much easier if we could just look at the source code.