Why not just check within the job script itself? You may design the script ( regression test ) to check if the software is already installed on this particular host, and install it if it isn't.
In this case you would not need to have 2 jobs at all. Sent from my iPhone > On Nov 7, 2017, at 3:26 AM, Arnau <[email protected]> wrote: > > 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
_______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
