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 <[email protected]> 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 >> [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
