Hi, before I never tried to set pmix plugin as the default in the slurm.conf.
Setting it in my new test installation highlighted the subject problem.
bug 2786

Bug 2787

C++ compilation against SPANK would fail otherwise.

>= 15.08 for some reports.

Needed to test ntasks_per_socket against both NO_VAL and INFINITE
for job allocaitons spanning multiple sockets.
bug 2766

Prevents correct error handling by rc being 0/1 instead of the original
return code.

Also fix slurm_send_only_controller_msg and slurm_send_only_node_msg
although these only result in bad printed values in the debug message.

Bug 2120

This bug was introduced by commit 21c52d2f
which fixed a different problem tracking resources associated with suspended
jobs. There are subtle differences between jobs that are suspended by a
user/administrator and jobs suspended by gang scheduling which resulted in
undercounting allocated CPUs when a job suspended by gang scheduling
was active at the same time of a slurmctld reconfiguration request.
See bugs 2353 (original bug related to commit 21c52d2f
and bug 2765

accounts) no default account is printed, previously NULL was printed.

This is just not printing it, but whole function should probably be
revisited as the rigmarole can probably be avoided as we always know what
the default is going to be if none is specified (first off the list).

The problem with that though is if the user has been added to a cluster
already and they have a default, but then added to a new cluster where
they don't have a default.  In this case you want to keep the first
clusters default, but set the default for the second cluster.

Bug 2725

Add missing unlock before return. Coverity 44888.

This reverts commit cc242de3
That patch fixed bug 2745, but breaks tests 1.89 and 1.91 on
typical Xeon processors

This bug was introduced by commit 21c52d2f
which fixed a different problem tracking resources associated with suspended
jobs. There are subtle differences between jobs that are suspended by a
user/administrator and jobs suspended by gang scheduling which resulted in
undercounting allocated CPUs when a job suspended by gang scheduling
was active at the same time of a slurmctld reconfiguration request.
See bugs 2353 (original bug related to commit 21c52d2f
and bug 2765

accounts) no default account is printed, previously NULL was printed.

This is just not printing it, but whole function should probably be
revisited as the rigmarole can probably be avoided as we always know what
the default is going to be if none is specified (first off the list).

The problem with that though is if the user has been added to a cluster
already and they have a default, but then added to a new cluster where
they don't have a default.  In this case you want to keep the first
clusters default, but set the default for the second cluster.

Bug 2725

Fix for uninitialized variable in task binding logic, could leave tasks
    with fewer CPUs than intended.
bug 2766

To quote our documentation: "... we know of no AIX installations
using Slurm after 2008." It certainly hasn't been tested there
recently and has presumably been broken for several releases.

Part 1: remove all build system linkages. Cleanup of HAVE_AIX ifdef
blocks will follow.

Add missing unlock before return. Coverity 44888.

Coverity 44891.

sizeof(optarg) is incorrect, that's the size of the pointer
not the length of the character string that must be parsed.

Coverity 53128.

Coverity 44992.

Needs to unlock here, not re-lock the lock.

Prevent '--preserve' from being inadvertanly enabled by '-j'.

Logic introduced in v16.05.0-rc2 could attempt state change for
nid00000, even if no such node exists
bug 2758

Change how Slurm determines the NUMA count of a node. Ignore KNL NUMA
    that only include memory.
bug 2745

Need thread_id to distinguish between multiple threads with the same
name.

and the slurmctld doesn't wait long enough for the response it would give
up leaving the connection open and create a situation where the next message
sent could receive the response of the first one.

Bug 2739

Correct logic that calculates a step's cpus_per_task allocation
on a heterogenous job allocation. Mixing a KNL with a Xeon resulted
in a count that was between the CPU count on the two node types
and invalid on the node with smaller CPU count (e.g. 272 CPUs on
KNL, 8 on Xeon, and 2 tasks, cpus_per_task = 140).

Bug #2713.

Bug #2713.