On Tue, Aug 13, 2013 at 06:07:53PM -0700, Christopher Samuel wrote: > > On 14/08/13 02:59, Andy Wettstein wrote: > > > If proctrack/cgroup is not being used, I don't think it is possible > > to properly track a process that does this. Since proctrack/cgroup > > can reliably track all PIDs for a step, then I think it should be > > able to track this. > > As I understand it Moe was saying that jobacct_gather/cgroup is buggy, > not proctrack/cgroup. We are using proctrack/cgroup here in > production on our x86 system that just went live and it seems to be > working so far (no users have screamed yet).
Right, I am using proctrack/cgroup and jobacct_gather/linux. The issue is that proctrack/cgroup knows all the PIDs for a job, but jobacct_gather/linux doesn't use the PIDs available from proctrack/cgroup to gather the job information. It tries to walk the process tree, which at least fails if a process in the job has its parent PID set to 1 (there may be other instances where that fails). My statement above is that if proctrack/cgroup is not being used, it would likely be impossible for jobacct_gather/linux to track those processes, but with proctrack/cgroup is should be possible for jobacct_gather/linux to track those. Maybe that was a little ambiguous in my wording. > > We did try jobacct_gather/cgroup but as Danny and Moe said it doesn't > collect information, possibly (as Ralph postulated in a thread I > started) because of confusion over signed/unsigned values (I was > seeing negative values of memory use reported for some cases). > > All the best, > Chris > -- > Christopher Samuel Senior Systems Administrator > VLSCI - Victorian Life Sciences Computation Initiative > Email: [email protected] Phone: +61 (0)3 903 55545 > http://www.vlsci.org.au/ http://twitter.com/vlsci > -- andy wettstein hpc system administrator research computing center university of chicago 773.702.1104
