[torqueusers] Dependencies among several jobs

[Michael Gutteridge]

We had a similar issue with multiple job dependencies.  We had to
reference all the way back to the top to get dependencies to work
properly, vis-a-vis:

1.job
2.job -> afterok: 1.job
3.job -> afterok: 1.job, afterok:2.job

Otherwise 3 was left around in the held state.  Haven't checked later
versions (this was 1.x when we had the troubles) to see if this was
still the case.



On Mon, 2006-08-28 at 16:47 +0100, David Golden wrote:
> On Friday 25 August 2006 23:44, Vincenzo Di Nicola wrote:
> 
> > create a script file: there I submit each single job, read
> > its jobid, and use the "-W depend=afterany" option with regard to the
> > previous job ids.
> 
> Well, that is what we tend to do, e.g. a simple string of 10 jobs:
> 
> #!/bin/bash
> HEADJOB=$(qsub -h myjob.pbs)
> echo $HEADJOB
> DEPJOB=$HEADJOB
> for i in $(seq 1 9); do
>   DEPJOB=$(qsub -W "depend=afterok:$DEPJOB" myjob.pbs)
>   echo $DEPJOB
> done
> qrls -h u $HEADJOB
> 
> 
> > But is there a nicer way to enforce dependencies, maybe without having to
> > rely on a jobid (but perhaps a job name)?
> >
> 
> Well, as far as I know, no.   Condor DAGman IIRC allows a more declarative 
> dependency graph specification method, but this is the Torque list :-)
> 
> (Aside: Lately (2.1.0p0) I think I'm seeing some weirdness where sometimes, 
> when the head job disappears (perhaps abnormally due to some system fault) 
> the dependent jobs don't notice, kinda like the dependency doesn't  "fire" 
> ("edge-" instead of "level-" triggered maybe?), and then left with a bunch of 
> held jobs in the queue.  Haven't pinned it down yet, and due an upgrade again 
> shortly anyway, may well just be an already-fixed bug or even intended 
> behaviour. Can't replicate on-demand, unfortunately)
> _______________________________________________
> torqueusers mailing list
> torqueusers at supercluster.org
> http://www.supercluster.org/mailman/listinfo/torqueusers