Original code by Damien François. <damien.francois@uclouvain.Be>

plugin fails to load.

place)

plugin

possible.  Otherwise if it fails it wouldn't happen to the slurmstepd
and might be missed by failing silently.

It will also mess up the packing/unpacking since it should be obvious if
it fails on the slurmctld.

slurmctld when starting up the jobacct_gather plugin.  It isn't needed
and makes errors in the slurmctld if not running as root.

Original patch from Martin Perry (Bull)

qos or any combination of those the correct thing happens.

If the job is using a QOS or Partition that only works inside a reservation
then deign the update if only removing the reservation.

we will read the old reservation used so if using a partition or qos
that only allows it to be used in a reservation we won't fail.

updating job so as to make sure the reservation is set correctly when
doing the other checks

previous versions of SLURM

Original Patch from Bill Brophy (Group Bull)

if a reservation is also requested in the job.

Original Patch from Bill Brophy (Group Bull)

The symptom is that SLURM schedules lower priority jobs to run when higher priority, dependent jobs have their dependencies satisfied.  This happens because dependent jobs still have a priority of 1 when the job queue is sorted in the schedule() function.  The proposed fix forces jobs to have their priority updated when their dependencies are satisfied.

Job priority of 1 is no longer used as a special case in slurm v2.4

The commit 8b14f388 on Jan 19, 2011 is causing problems with Moab cluster-scheduled machines.  Under this case, Moab hands off every job submitted immediately to SLURM which gets a zero priority.  Once Moab schedules the job, Moab raises the job's priority to 10,000,000 and the job runs.

When you happen to restart the slurmctld under such conditions, the sync_job_priorities() function runs which attempts to raise job priorities into a higher range if they are getting too close to zero.  The problem as I see it is that you include the "boost" for zero priority jobs.  Hence the problem we are seeing is that once the slurmctld is restarted, a bunch of zero priority jobs are suddenly eligible.  So there becomes a disconnect between the top priority job Moab is trying to start and the top priority job SLURM sees.

I believe the fix is simple:

diff job_mgr.c~ job_mgr.c
6328,6329c6328,6331
<       while ((job_ptr = (struct job_record *) list_next(job_iterator)))
<               job_ptr->priority += prio_boost;
---
       while ((job_ptr = (struct job_record *) list_next(job_iterator))) {
               if (job_ptr->priority)
                       job_ptr->priority += prio_boost;
       }
Do you agree?

Don