isn't doing the launching.

updated the srun man page.

sched/backfill - Prevent possible memory corruption due to use of
bf_continue option and long running scheduling cycle (pending jobs could
have been cancelled and purged).

Change max message length from 100MB to 1GB before generating "Insane
message length" error.

can only be a TORUS (1).

This specifies the maximum depth the backfill scheduler should go
in any single partition.

srun is pending.  The step creation would use the old values and possibly
hang srun since the step wouldn't be able to be created in the modified
allocation.

into the future.

bug 428

for setdebugflags command, avoid parsing "-flagname" as
an scontrol command line option.

for CR_Socket.

Add support for "on" and "before*" options

bugfixes and the new item extraction feature.

Set PBS_ACCOUNT, PBS_ENVIRONMENT, and PBS_QUEUE only for batch
jobs and only if the user submission sets the account and partition.

No support for PBS "before" options

-l accelerator=true|false	(GPU use)
-l mpiprocs=#	(processors per node)
-l naccelerators=#	(GPU count)
-l select=#		(node count)
-l ncpus=#		(task count)
-v key=value	(environment variable)
-W umask=#		(set job's umask)
Note: the -v option does NOT support quoted commas.

-l accelerator=true|false	(GPU use)
-l mpiprocs=#		(processors per node)
-l naccelerators=#	(GPU count)
-l select=#		(node count)
-l ncpus=#		(task count)
-v key=value		(environment variable)
-W umask=#		(set job's umask)

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. */

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

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