[GE users] exit status for completed jobs

Jeff White jsw at farecast.com
Fri Mar 16 00:49:50 GMT 2007


    [ The following text is in the "ISO-8859-1" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some special characters may be displayed incorrectly. ]

Where is the "usage" file in your script that has the exit_status? Is it 
called something else now?

Is the epilog executed on each exec host, possibly causing resource 
contention if updating a database, or is it serially executed on the 
qmaster for each job? Is there documentation on all the environment 
variables that are available?

jeff


Chris Dagdigian wrote:
> 
> This code snippet came from an old project where we needed to scan job 
> output files for evidence of license related failures.
> 
> At the very least it confirms that epilog scripts have access to 
> exit_status:
> 
> 
>  #!/bin/sh
>  # Simple epilog script
>  JOB_EXIT_STATUS="`sed -ne 's/^exit_status=//p' \ 
> $SGE_JOB_SPOOL_DIR/usage | tail -1`"
>  echo "--------"
>  echo "Job exited code: $JOB_EXIT_STATUS"
>  echo "Job output should be in directory $SGE_WORKDIR"
>  echo "--------"
> 
> 
> -Chris
> 
> 
> 
> 
> On Mar 14, 2007, at 6:45 PM, Jeff White wrote:
> 
>> I know this has been brought up before, but am wondering the latest..
>>
>> From Java, what is the best way to find the exit_status for jobs that 
>> completed in a previous session?
>>
>> I imagine that my application writes the jobId to a database as each 
>> job is submitted. While my application is running, it uses 
>> session.wait() to get completion status of jobs. I would like the 
>> flexibility to restart my application and have it query the status of 
>> all jobs that I haven't heard back from, including ones that finished 
>> while I wasn't running. It seems the options are:
>>
>>   - call out to qacct (log grep is too slow)
>>
>>   - create an epilog script that writes job information to a database. 
>> I           don't know if epilog has access to exit_status etc.
>>
>>   - ARCo: is it available for 6.0? I imagine, however, that there 
>> would be a delay in data flowing from the reporting file to the 
>> database, so there would always be the possibility of jobs that are 
>> temporarily "unknown". I don't always need to know the most current 
>> status of every job, but should at least be able to get the last known 
>> status of any job.
>>
>> jeff
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>> For additional commands, e-mail: users-help at gridengine.sunsource.net
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
> 

-- 
science not marketing

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list