Hi, I was thinking in a solution like the one Reuti proposed:
modify the init script so it writes some file in /tmp and then add a complex that checks if file exists. If it's there, the coplmex=false. Then, your setup job should remove the file once it finishes. HTH, Arnau 2017-11-07 0:08 GMT+01:00 Reuti <[email protected]>: > > > Am 06.11.2017 um 23:54 schrieb Reuti <[email protected]>: > > > > > >> Am 06.11.2017 um 22:29 schrieb Simon Matthews < > [email protected]>: > >> > >> I need to run a job on every execd host that must be run before the > >> main batch of jobs are run. > >> > >> I could submit a "setup" job on each specific execd host and make all > >> the subsequent jobs dependent on the list of "setup" jobs, but, if one > >> setup job gets hung up, all the subsequent jobs will wait, even though > >> they could be executed on other execd hosts. > >> > >> Is there some way to prevent jobs from running on a particular execd > >> hosts until after a "setup" job has run on that host? Or, to put it > >> another way, the setup job enables other jobs to run on the execd > >> host? > > > > Under which user account should the "setup" job run? Is this a necessity > for the cluster or just your user? > > > > One could introduce a BOOL/FORCED complex and prepare it with FALSE for > all exechosts. The "setup" job will request "-l prepared=FALSE", maybe > combined with an exclusive complex so that only one "setup" job will run > per exechost. At the end of the job the "setup" job has to change the value > of the complex for this particular exechost to TRUE. Essentially no > additional "setup" can start on this exechost any longer. > > > > The normal jobs on the other hand will request "-l prepared" resp. "-l > prepared=TRUE". > > BTW: If you don't like that the job has permissions to change the settings > of SGE: it could also use a file instead and a load sensor will return > FALSE/TRUE depending on the existence, size, value… of a particular file > (top level of tmpdir would be feasible). > > > > > -- Reuti > > _______________________________________________ > > users mailing list > > [email protected] > > https://gridengine.org/mailman/listinfo/users > > > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users > >
_______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
