bg.properties in order for the runjob_mux to run correctly.

Signed-off-by: Danny Auble <da@schedmd.com>

c++

but job is going to be canceled because it is interactive or other reason
it now receives the grace time.

check if a block is still makable if the cable wasn't in error.

removal of the job on the block failed.

29d79ef8

same time a block is destroyed and that block just happens to be the
smallest overlapping block over the bad hardware.

The underlying problem is in the sched plugin logic in SLURM v2.4

but not node count the node count is correctly figured out.

Without this fix, gang scheduling mode could start without creating
a list resulting in an assert when jobs are submitted.

This change permits a user to get a zero size allocation by specifying
a task count of zero with no node count specification.

packing the step layout structure.

we must use a small block instead of a shared midplane block.

still messages we find when we poll but haven't given it back to the real
time yet.

I was doing some checking to find out why the the 2.4 branch and
master branch of schedmd was not allowing held jobs to be modified,
when attempting to do so,  scontrol would return:

slurm_update error: Requested partition configuration not available now

I did some debugging and found that it was caused by code added to the tail end
of job_limits_check() in job_mgr.c. It  had this addition:

        } else if (job_ptr->priority == 0) {   /* user or administrator hold */
                fail_reason = WAIT_HELD;
        }

It is causes all modifications done by scontrol on held jobs, to fail.

I'd like to propose quieting down the job_mgr a tad.  This is a refinement to:
https://github.com/SchedMD/slurm/commit/30a986f4c600291876f4ec3e3949934512f2cba5