Sorry for missing that one. It is a related patch:
Index: src/scontrol/update_job.c
===================================================================
--- src/scontrol/update_job.c (revision 22807)
+++ src/scontrol/update_job.c (working copy)
@@ -246,7 +246,7 @@
job_msg.priority = 0;
job_msg.alloc_sid = 0;
} else
- job_msg.priority = 1;
+ job_msg.priority = INFINITE;
if (slurm_update_job(&job_msg))
return slurm_get_errno();
________________________________________
From: [email protected] [[email protected]] On Behalf
Of Bjørn-Helge Mevik [[email protected]]
Sent: Friday, March 18, 2011 7:57 AM
To: [email protected]
Subject: Re: [slurm-dev] Possible bug: scontrol hold not possible when grpcpus
is set
"Jette, Moe" <[email protected]> writes:
> Index: src/slurmctld/job_mgr.c
> ===================================================================
> --- src/slurmctld/job_mgr.c (revision 22720)
> +++ src/slurmctld/job_mgr.c (revision 22721)
> @@ -6306,6 +6306,10 @@
> } else
> job_ptr->state_reason = WAIT_HELD_USER;
> xfree(job_ptr->state_desc);
> + } else if ((job_ptr->state_reason == WAIT_HELD) ||
> + (job_ptr->state_reason == WAIT_HELD_USER)) {
> + job_ptr->state_reason = WAIT_NO_REASON;
> + xfree(job_ptr->state_desc);
> }
> } else if ((job_ptr->priority == 0) &&
> (job_ptr->state_reason == WAIT_HELD_USER)) {
Thanks! That cleares the reason field.
But the priority is still not set back to its normal value; it stays at
1. But there is perhaps a good reason for that?
--
Bjørn-Helge Mevik, dr. scient,
Research Computing Services, University of Oslo
