itty bitty IRIX questions

Dave Olson olson at anchor.esd.sgi.com
Mon Jun 3 05:15:13 AEST 1991


In <9106020322.AA12664 at crow.omni.co> rpaul at 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.



More information about the Comp.sys.sgi mailing list