runjob_mux.

0c00d359

for better debug

midplane block that starts on a higher coordinate than it ends (i.e if a
block has midplanes [0010,0013] 0013 is the start even though it is
listed second in the hostlist).

It has been changed to improve the calculated value for pending
jobs and use the actual node count value for jobs that have been
started (including suspended, completed, etc.)
bug 549

that spans multiple midplanes the cnodes are correctly accounted for that
are in error.

being in error.

Note that each job's node allocation is counted separately.
bug 548

will return ENOTCONN and not initialize the addr_str causing valgrind
errors.

This allows multiple job ids to hold, uhold, resume, suspend, release, etc.

226b49a3

Test would periodically fail due to expect timing.
This seems to fix the problem

Fix slurmstepd race condition when separate threads are reading and
modifying the job's environment, which can result in the slurmstepd failing
with an invalid memory reference. Observed at shutdown when trying
to run the task epilog and trying to read the env var:
SLURM_STEP_KILLED_MSG_NODE_ID

We do not want to look at the core file, so avoid generating it
and then having to manually clear it later.

Without this change, sstat would try to unpack accounting data
that was never packed, resulting in message unpack errors.

There were some parsing issues and the test was not as general
as it should have been

throw away initialized variable.

Without this patch, free() is called on a random memory location
(i.e. whatever is on the stack), which can result in slurmstepd
dying and a completed job not being purged in a timely fashion.

Fix race condition in authentication credential creation that could corrupt
memory. (NOTE: This race condition has existed since 2003 and would be
exceedingly rare.)

This is needed for job arrays with discontiguous task ID values
(e.g. "123_[1,3,5,...99999]")

Previously job arrays were only listed with their native job ID
(e.g. 123_0 listed as 123, 123_1 as 124, etc). Now lists the job ID
using both format (e.g. "123_1 (124)"). The same format is used
for job step IDs (e.g. "123_1.2 (124.2)").

If the GRES is associated with specific files AND
the GRES count is reset using scontrol AND
the slurmd is restarted either without a gres.conf file or with a count and no specific files AND
the GRES count is then increased using scontrol the GRES bitmap will not match its count

This fixes the root cause of the mismatch between bitmap size and GRES
count and should render the rebuilding of the bitmap unnecessary.
The rebuilding was handled in the following commits
commit ec4df3bf
commit 1712d619