At 2007-07-10T15:00:32+1200, John Carter wrote:
>> I suspect all the info is there in /proc/self/status
Not all, and not in that file. You'd be better to start with
/proc/<PID>/stat and statm, which are machine readable.
There is a bunch of really useful information in /proc/<PID>, some of which
is parsed and displayed by tools from the psutils package, some of which
there are ad-hoc tools to deal with, and some of which isn't used by
userspace (yet). One of the more useful recent additions is
/proc/<PID>/smaps, which is useful for examining the address space of a
process to get a picture of the real memory use.
>> * Looks up command on path.
Just let execvp(3) (or another exec.*p variant) do the work. Duplicating
the system/shell path search code would be a waste of effort.
>> * forks & execs it.
>> * Somehow catches the exit and before /proc/pid/status vanishes...
One way to do it is to have the parent install a SIGCHLD handler and read
the child's files from /proc before waiting on the child. Another way is to
use getrusage(2) rather than trying to read /proc, but see below. Yet
another is to use ptrace(2) to cause the child to read it's own /proc files
by injecting code into the exit path.
>> * cats /proc/pid/status to stderr
Better to copy the data to a user-specified file rather than mess with the
(shared) stderr channel.
> So I thought I'd spend the 5 minutes...
>
> The crux of the problem is to catch the child process before
> /proc/pid/status disapppears.
>
> So I started looking at "wait" calls and found wait4... Aha! It gets all
> the details I need...
>
> Hmm... Let's strace /usr/bin/time....
>
> Bugger.
>
> It uses wait4 and the values are crap there already. ie. The problems
> not /usr/bin/time, it's deeper in.
time(1) is one of the problems--it's showing the user data that has never
had sane values on Linux.
The lower level problem is that time(1) uses struct rusage. The problem
here is that struct rusage is underspecified by POSIX, and Linux only
bothers to do accounting for some of the fields (more than POSIX specifies,
but still not everything that struct rusage contains). The man page for
getrusage on Linux (and kernel/sys.c for the undocumented fields) indicates
that only the following fields are updated:
2.4 kernels: ru_utime, ru_stime, ru_minflt, ru_majflt
2.6 kernels: as above, plus ru_nvcsw, ru_nivcsw
undocumented: as above, plus ru_inblock, ru_outblock
This corresponds with the fields that have sane values in the output of
time(1).
> Ah well, let's not bother with that then...
You never specified which fields you're interested in. If you really want
everything that time(1) promised to tell you, you're out of luck. If you're
interested in collecting statistics for specific things, there are almost
definitely good tools already available to help you out.
Cheers,
-mjg
--
Matthew Gregan |/
/| [EMAIL PROTECTED]
