Am 12.09.2012 um 14:00 schrieb Lars van der bijl:

> so in the epilog i've added the code to re-queue the task but now it's
> dependencies won't start.
> anyway to get those to start while retaining the parent task in the queue?

Not directly, as the job numbers are checked for the dependences (even if you 
used a jobname for -hold_jid at submission time). As long as the job is in the 
system (waiting or running) no jobs having -hold_jid for this jobs will start.

With "dormant" then you in fact mean to different states: start the follow up 
jobs or not.

In case you want to document something: you could use "qresub -h $JOB_ID". This 
will submit a copy of the job (with a new job id) and have the hold state 
attached.

-- Reuti


> On 12 September 2012 13:13, Lars van der bijl <[email protected]> wrote:
>> aa ok.
>> 
>> thanks Reuti. thanks for taking the time to help me out with these things.
>> 
>> On 12 September 2012 13:11, Reuti <[email protected]> wrote:
>>> Am 12.09.2012 um 13:08 schrieb Lars van der bijl:
>>> 
>>>> On 11 September 2012 17:25, Reuti <[email protected]> wrote:
>>>>> Am 11.09.2012 um 17:20 schrieb Lars van der bijl:
>>>>> 
>>>>>> hey reuti.
>>>>>> 
>>>>>> is there a way to verify that the terminate_method is being run? i
>>>>>> assume it's run in the exec host but as what user?
>>>>> 
>>>>> Put a "sleep 60" therein and check on the node in question by a process 
>>>>> listing.
>>>> 
>>>> just did a little test and it only works if i qdel the task. it
>>>> doesn't seem to fire if a task finishes normally.
>>>> is this expected?
>>> 
>>> Sure, there is nothing to be terminated in this case.
>>> 
>>> The nomal exit you handled in the epilog as you said.
>>> 
>>> 
>>>> I'd want every task to be put in a hRq state
>>> 
>>> Each and every - even a successful run? You can put a similar logic in the 
>>> epilog.
>>> 
>>> -- Reuti
>>> 
>>> 
>>>>> 
>>>>> -- Reuti
>>>>> 
>>>>> 
>>>>>> I can't seem to get it to do anything.
>>>>>> 
>>>>>> 
>>>>>> On 11 September 2012 00:33, Reuti <[email protected]> wrote:
>>>>>>> No, the "terminate_method" in the queue definition and will be called 
>>>>>>> to terminate the job. Before killing the process, we reschedule the 
>>>>>>> job. And maybe you have to fiddle with $SGE_TASK_ID here too.
>>>>>>> 
>>>>>>> The prolog would executed before the job.
>>>>>>> 
>>>>>>> -- Reuti
>>>>>>> 
>>>>>>> Am 10.09.2012 um 23:26 schrieb Lars van der bijl 
>>>>>>> <[email protected]>:
>>>>>>> 
>>>>>>>> On 10 September 2012 17:57, Reuti <[email protected]> wrote:
>>>>>>>>> Am 10.09.2012 um 17:46 schrieb Reuti:
>>>>>>>>> 
>>>>>>>>>> <snip>
>>>>>>>>>> Okay, now I see. You could use a script like:
>>>>>>>>> 
>>>>>>>>> Ups:
>>>>>>>>> 
>>>>>>>>>> #!/bin/sh
>>>>>>>>>> . /usr/sge/default/common/settings.sh
>>>>>>>>>> qalter -h u $JOB_ID
>>>>>>>>>> qmod -rj $JOB_ID
>>>>>>>>>> kill -9 -- -$1
>>>>>>>>>> 
>>>>>>>>>> for the "terminate_method $job_pid" the queue definition. Seeing 
>>>>>>>>>> "hRq" as a dormant state.
>>>>>>>>> 
>>>>>>>>> "terminate_method path_to_your_script $job_pid"
>>>>>>>> 
>>>>>>>> do you mean the prolog? so that after the task finishes we put it back
>>>>>>>> in a hold state?
>>>>> 
>>> 


_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users

Reply via email to