[gridengine users] qstat XML output: resource requests: submission time values vs qaltered values (GE 6.2u5)
reuti at staff.uni-marburg.de
Wed Feb 29 12:29:40 UTC 2012
Am 29.02.2012 um 03:31 schrieb Kevin Buckley:
> was recently trying to get some info from the XML output from a "qstat -j" and
> noticed that for two running jobs, the s_rt value that had been supplied in two
> different ways, appeared within two different "XPaths"
> A job that had supplied the s_rt limit as a submission request sees
> the XML place the
> value at a "path" identifiable as
> whereas a job which had had the s_rt limit added in, via a qalter
> whilst still in the queue, saw it turn up as
> I can see why the two would be different (because they are!) but, once
> I had discovered
> that there were two paths to the "same info", wondered if, once a job
> was running and
> so limits such as s_rt had become immutable, they would be better
> represented by the
> second form, ALONG with the first, if values had been specified that way.
> Do the internal structures of the GE code maintain both "submitted"
> and "allocated" values,
> so that this might be possible ?
I would say no. There are some traces in the sources that it might be available later, but for now these are dummy entries:
handler->job_handler.report_soft_resources_started = qstat_xml_dummy_started;
handler->job_handler.report_soft_resource = qstat_xml_job_soft_resource;
handler->job_handler.report_soft_resources_finished = qstat_xml_dummy_finished;
It's of course interesting, that by changing the request the name in the XML output changes. In the normal `qstat -j <job_id>` output an additional entry "version:" will reflect that there was a change.
The accouting file only records the last known values too.
If you want to have a way to check the original values: a JSV could copy the original supplied values into a job context (-ac ...). I don't know, whether this would be suitable for you, as the user could also change the values in the job context. And after the job the job context is gone too.
I use the job context to store some other stuff, and send it with the usual job email to the user by extending it in a email-wrapper. You could output in the email both: job context values (supposing they werent changed), and the last known values. Please let me know if you want to use it, as there are some pitfalls to note (mainly: the email is set after the job left the node already).
> Kevin Buckley
> ECS, VUW, NZ.
> users mailing list
> users at gridengine.org
More information about the users