On Tue, Apr 24, 2012 at 02:33:15PM -0700, Matthew Dempsky wrote: > On Thu, Apr 19, 2012 at 7:26 AM, Marc Espie <es...@nerim.net> wrote: > > On Thu, Apr 19, 2012 at 02:57:57PM +0100, Stuart Henderson wrote: > >> On 2012/04/19 15:42, Marc Espie wrote: > >> > Yeah, the only issue so far is that the make-wrapper process is C code, > >> > so > >> > it needs to be compiled and deployed on every host > >> > >> we ship with a wrapper in base ;) > >> > >> /usr/bin/time -l > > > > Up to a point. This means parsing the log files to find that entry. > > Nah, just direct time's output to a different file: > > $ cat logtime > #!/bin/sh > fn="$1"; shift > exec /usr/bin/time -l sh -c 'exec "$@" 2>&9 9>&-' -- "$@" 9>&2 2>"$fn" > $ ./logtime time.out sh -c 'echo stdout; echo stderr >&2' > stdout > stderr > $ cat time.out > 0.00 real 0.00 user 0.00 sys > 504 maximum resident set size > 0 average shared memory size > 0 average unshared data size > 0 average unshared stack size > 146 minor page faults > 0 major page faults > 0 swaps > 0 block input operations > 0 block output operations > 0 messages sent > 0 messages received > 0 signals received > 0 voluntary context switches > 0 involuntary context switches > > :) Well, yuck, this makes for ways too many extra processes just for that. If I have to deploy code, it's almost as easy to compile an extra program on the fly...
> > It's feasible, > > but not really nice... and /usr/bin/time will fail on some signals. > > Hm, how so? when you kill a job, you want to report current rss to extract stats later. /usr/bin/time will die without having reported anything on at least some current signals, namely it only catches INT and QUIT...
