deamon help

[Chris Torek]

>From: jfh at rpp386.cactus.org (John F Haugh II)
>>... One problem I envision with the PS approach is that the CPU
>>resolution is to the full second, and there are many processes which
>>lurk about in the background and don't use much more than a second
>>in a days time.

In article <BZS.91Feb6211712 at world.std.com> bzs at world.std.com
(Barry Shein) writes:
>Looks like we need another option to ps...to increase clock res.

4.3reno++ (4.3785?) already gives time to 10 ms resolution:

% ps u
USER       PID %CPU %MEM   VSZ  RSS TT  STAT STARTED       TIME COMMAND
torek     9409 13.3  0.7   128   55 q1  R+    2:28AM    0:00.27 ps u
torek     9339  0.2  0.7   150   37 q1  Ss    1:10AM    0:01.85 -csh (csh)

>Seriously, grokking around in the kernel proc structures tends to be
>fraught with peril unless you're really pre-disposed to that sort of
>thing.

Actually, there is a more basic problem, at least under 4BSD.  It is
not difficult to write a program that uses 80 to 90 % of the total
available CPU time yet shows 0% CPU usage.  This is due to a phase
interaction between the scheduler and the process accounting code.
They both run off the same clock, and you can rig things so that your
process is not running when the next clock interrupt fires.

I will not give out the details here, since defeating the accounting
code causes the scheduler to think that your process is being bullied
and thus it gets higher priority than all the others, allowing it to
continue in its evil ways.  In other words, this goofs up the usual
resource sharing, and someone could use it to hog all the cycles.

(Fortunately, if someone *does*, and two people do it, the two processes
wind up exposing each other's tricks.  The clever bad guy will find a
way around this as well [such a way does exist].)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov