Fix error handling for job array create failure due to inability to copy
job files (script and environment).
See bug 1077

are hard links to the first element specification files. If the
controller fails to make the links the files are copied instead.

reserved for higher priority jobs.

since the slurmd will send the same message.

correctly.

ran inside the allocation can read the environment correctly.

This fixes some problems creating advanced reservations on heterogeneous systems, especially when core counts are specified in the reservation.
bug 1068

Make "srun --gres=none ..." work when executed without a job allocation
(i.e. srun creates the allocation plus the step). Previous logic would
try to create the job with a gres value of "none".

Fix for possible error if job has GRES, but the step explicitly requests a
GRES count of zero.

and only caused confusion since the cpu_bind options mostly refer to a
step we opted to only allow srun to set them in future versions.

Defer job step initiation of required GRES are in use by other steps rather
than immediately returning an error.
bug 1056

had --network= specified.

ProfileHDF5Dir directory as well as all it's sub-directories and files.

be used for AcctGatherFilesystemType.

srun properly interprets a leading "." in the executable name based upon
the working directory of the compute node rather than the submit host.

script that will use it.

states.

has finished)

timeout when talking to the Database is the same timeout so a race
condition could occur in the requesting client when receiving the response
if the database is unresponsive.

the entire cnode.

Fix SelectTypeParameters=CR_PACK_NODES for srun making both job and step
resource allocation. Previously a stand-long srun command would distribute
tasks evenly across the nodes.

Start a job in the highest priority partition possible, even if it requires
preempting other jobs and delaying initiation, rather than using a lower
priority partition. Previous logic would preempt lower priority jobs, but
then might start the job in a lower priority partition and not use the resources
released by the preempted jobs.
bug 1032

Previously job would only run in first listed partition.

Fix gang scheduling for jobs submitted to multiple partitions.
Previous logic assumed the job's "partition" field contained a
single partition name, that in which the job is running. That
was recently changed in order to support job's being requeued,
which we want to be runable in all of it's valid partitions.

signal 1.

done for normal steps.

of acting like it is a signal and exitcode.

previous it was always -2.