Thanks for the input.... Comments below.
On Fri, Jan 13, 2012 at 7:26 AM, Reuti <re...@staff.uni-marburg.de> wrote: > Hi, > > Am 13.01.2012 um 02:03 schrieb Reuti: > >> <snip> >> But a nice solution could be the usage of the job context. This can be set >> by the user on the command line, and your job can access this by issuing a >> similar command like you did already. If the exechosts are submit hosts, the >> job can also change this by using `qalter` like the user has to use on the >> command line. We use the job context only for documentation purpose, to >> record the issued command and append it to the email which is send after the >> job. >> >> http://gridengine.org/pipermail/users/2011-September/001629.html > > as the usage of a job context may be a seldom used feature, let me elaborate > this and post an example. Imagine you have a jobscript: > > =================== > #!/bin/bash > . /usr/sge/default/common/settings.sh > > STATE_OLD=EMPTY > while true; do > while read LINE; do > case ${LINE%%=*} in > STATE) STATE=${LINE#*=} ;; > LEVEL) LEVEL=${LINE#*=} ;; > esac > done < <(qstat -j $JOB_ID | sed -n -e "/^context/s/^context: *//p" | tr > "," "\n") > if [ "$STATE" != "$STATE_OLD" ]; then > STATE_OLD="$STATE" > echo "STATE was changed to: $STATE" > fi > if [ "$STATE" = "EXIT" ]; then > break > fi > sleep 5 > done > > echo "Process completed." > > exit 0 > =================== > > and you submit this with: > > $ qsub -ac STATE=INIT test.sh > Your job 3686 ("test.sh") has been submitted > > and after each 5 seconds: > > $ qalter -sc STATE=PROCESS 3686 > modified context of job 3686 > $ qalter -sc STATE=COMPRESSION test.sh > modified context of job 3686 > $ qalter -sc STATE=SAVING 3686 > modified context of job 3686 > $ qalter -sc STATE=EXIT test.sh > modified context of job 3686 > > In another window you can follow the output: > > $ tail -f test.sh.o3686 > STATE was changed to: INIT > STATE was changed to: PROCESS > STATE was changed to: COMPRESSION > STATE was changed to: SAVING > STATE was changed to: EXIT > Process completed. > > > By using a job context (which can be changed by the user or by the job itself > [and then checked with `qsub -j 12345` on the command line by the user]) the > user can influence the operation of the job as well as the job can output its > internal state or commenting information, without the need to print it in the > output file or the use of any file which you have to change and read. This does look interesting. We have never made use of contexts. My only concern would be the continual qstats that the jobs would be running. It seems like if I had hundreds or thousands of jobs using this methodology, it would put quite a bit of strain on the server. What kind of scale have used this in? Thanks again for taking the time to provide this info. > > -- Reuti -- -MichaelC _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
