rusage of an active child process?

Kenneth Almquist ka at june.cs.washington.edu
Thu Jan 5 19:09:42 AEST 1989


rohlicek at bbn.com (Robin Rohlicek) writes:
> What is good way to obtain an rusage structure for an active child
> process?  Both getrusage(2) and wait3(2) are most useful after the
> child has terminated.  The closest I've been able to get from the
> documentation is
> 
> 	kill(child_pid,SIGSTOP);
> 	pid = wait3(&status,WNOHANG|WUNTRACED,&rusage);
> 	kill(child_pid,SIGCONT);
> 
> which seems to work.  It seems that it should be unnecessary to stop
> the child, or is this something fundamental about the way unix handles
> processes?

The above code won't work.  The way UNIX handles the rusage structure is
as follows.  When a UNIX process exits, the kernel stuffs the rusage
information into the process structure, overwriting fields that normally
contain other information but which are not used once the process is
terminated.  The process structure remains allocated until the process
is waited for.  At that point the wait system call pulls the rusage
information out of the process structure and then frees the process
structure.

When a process is stopped, the kernel can't store the rusage information
in the process structure because storing the information would overwrite
fields that have other purposes and are needed for stopped (as opposed
to terminated) processes.  So the rusage values returned by wait3 for
stopped processes are garbage.  Or in the words of the 4.3 BSD manual
page for wait3, "If rusage is non-zero, a summary of the resources used
by the terminated process and all its children is returned (this infor-
mation is currently not available for stopped processes)."

Unfortunately, there simply isn't a good way to get resource information
on running processes.  The ps command will print CPU times.  If you have
the source for the ps command and sufficient privileges to run your own
version of ps, you can create a modified version of ps that prints out
more resource information.
				Kenneth Almquist



More information about the Comp.unix.wizards mailing list