[gridengine users] will changes to a hard limit in a queue config roll down into running jobs?

Rayson Ho rayson at scalablelogic.com
Thu Nov 15 16:59:59 UTC 2012


I just checked the source, "JB_hard_wallclock_gmt" (which is an execd
internal data structure first set when the job starts running, and the
value is pulled from h_rt) is only handled by the execd, so if the
execd is not running (just do what Reuti mentioned in his email
below), then the job *should* continue to run after exceeding the
wallclock limit.

(Of course, we will need some testing to make sure this kind of hacks
would work in a production environment. I would at least test with a 1
node cluster and a queue with 3-min wallclock limit before really
doing anything with the real job.)

Rayson



On Thu, Nov 15, 2012 at 11:34 AM, Reuti <reuti at staff.uni-marburg.de> wrote:
> Am 15.11.2012 um 17:20 schrieb Chris Dagdigian:
>
>> Quick question ...
>>
>> I've got a job with a user running in a queue that has a 48 hour hard wallclock limit. The user is prepared to move into a long.q but his job is *almost* complete and will not go much past the 48h limit. Trying to see if I can preserve the job and not lose 48 hours of computation...
>>
>> If I relax or remove the hard limit from the cluster queue config temporarily will the job be spared? Do changes to these limits get passed down dynamically to running jobs.  I can't remember if I've ever had this particular scenario come up before...
>
> Never tried that, but this will work:
>
> http://gridengine.org/pipermail/users/2012-January/002432.html
>
> -- Reuti
>
>
>> Regards,
>> Chris
>>
>>
>> _______________________________________________
>> users mailing list
>> users at gridengine.org
>> https://gridengine.org/mailman/listinfo/users
>
>
> _______________________________________________
> users mailing list
> users at gridengine.org
> https://gridengine.org/mailman/listinfo/users




More information about the users mailing list