This removes logic added three years ago that would automatically set a job's cpus_per_task value in order to reset a job's mem_per_cpu value and scale the cpus_per_task by the same value. Equivalent logic did not exist in the step allocation logic. Just return an error instead. This change will be made in Slurm version 2.6, but this batch is made for version 2.5. The original patch introducing the problem is in commit: cc00cc70bug 352

Bug 351

This is extends the logic of commit
ba58d59c
to the following RPC types:
job complete
batch script complete and
job step complete

Related to bug 326

We've seen expect not pick up the full user name in some cases,
but truncate it.

Note, we are switching to the ubuntu version numbering scheme:
last two digits of the year for the major version number
month number for the minor version number
13.12 == 2013 December

In acct_gather_energy/rapl initialization, if the fopen of /proc/cpuinfo fails we should treat this as a fatal condition rather than continue.  Patch is attached.

Problem found by Coverity tool, CID 20186
bug 331

This applies the same logic as added for job signal and batch job
submit as in commit ba58d59c

is larger than the number of tasks spread across the node.

since neither of those should be divided by 100 instead of 1024.

divisible by 1024.

future.

for as the job/step id.

The SLURM Makefile.am scripts use pkglibexecdir. One source indicates
that this was not added until automake 1.10.2
(https://github.com/rerun/rerun/issues/167).

So we just made that to be the minimum.

The logic added to wake pending job steps as soon as resources become
available lacked signal handling logic. This adds signal handling logic.
Fix for bug 339

Under very heavy load with many thousands of batch job submissions
or job signals, the write lock can be held for very long periods of
time preventing job scheduling, squeue response, etc. This code
inserts a timing break to permit other functions to get the locks.