that ended in the OverTimeLimit interval.

Caused by allocating single adapter per node of specific adapter type.

Previous logic would pick CPUs then
reject jobs that can not match GRES to the allocated CPUs. New logic first
filters out CPUs that can not use the GRES, next picks CPUs for the job,
and finally picks the GRES that best match those CPUs.
bug 410

Report anything that is world writable.

/* Current code (<= 2.1) has it so we start the new
 * job with the next step id.  This could be used
 * when restarting to figure out which step the
 * previous run of this job stopped on. */

The Cray version of those libraries must be used.
bug 407

See
https://groups.google.com/forum/#!topic/slurm-devel/j4izr0L4w8w

switch/generic - propagate switch information from srun down to slurmd and
slurmstepd. Previously the information was not going past the srun
command.

due to multiple free calls caused by job arrays submitted to
multiple partitions. The root cause is the job priority array
of the original job being re-used by the subsequent job array
entries. A similar problem that could be induced by the user
specifying a job accounting frequency when submitting a job
array is also fixed.
bug 401

sacctmgr.

If reservation create request included a CoreCnt value and more
nodes are required than configured, the logic in select/cons_res
could go off the end of the core_cnt array. This patch adds a
check for a zero value in the core_cnt array, which terminates
the user-specified array.
Back-port from master of commit 211c224b

If reservation create request included a CoreCnt value and more
nodes are required than configured, the logic in select/cons_res
could go off the end of the core_cnt array. This patch adds a
check for a zero value in the core_cnt array, which terminates
the user-specified array.

the node health check script for steps and allocations respectfully.

Used job terminations due to failure to boot it's allocated nodes
or BlueGene block.
bug 213

This is a correction of a bug introduced in commit
https://github.com/SchedMD/slurm/commit/ac44db862c8d1f460e55ad09017d058942ff6499
That commit eliminated the need of reading the node state information
from squeue for performance reasons (mostly for large parallel systems
in which the Prolog ran squeue, which generates a lot of simultaneous
RPCs, slowing down the job launch process). It also assumed 1 CPU per
node. If a pending job specified a node count of 1 and a task count
larger than one, squeue was reporting the node count of the job as
the same as the task count. This patch moves that same calculation
of a pending job's minimum node count into slurmctld, so the squeue
still does not need to read the node information, but can report the
correct node count for pending jobs with minimal overhead.

to avoid it thinking we don't have a cluster name.

to avoid it thinking we don't have a cluster name.

%o and %Z respectively

If there are completing jobs, a reconfigure will set wrong job/node
state: all nodes of the completing job will be set allocated, and the
job will not be removed even if the completing nodes are released. The
state can only be restored by restarting slurmctld after the completing
nodes released.

Added boards_per_node, sockets_per_board, ntasks_per_node,
ntasks_per_board, ntasks_per_socket, ntasks_per_core, and nice.

This makes it consistent with the value of default_queue_depth.
The backfill scheduler should be able to easily handle this value
(or much higher for pretty much any configuration).