Bug 3447

Bug 3444

These were false positive error reports, but should go away now.

Bug 3406.

Fix srun I/O race condtion to eliminate a error message that might be
    generated if the application exits with outstanding stdin.
bug 3166

# Conflicts:
#	META
#	NEWS

Use instead of the repeated construction of:
bit_not(b); bit_and(a, b); bit_not(b);
to avoid two addition iterations.

Can't set the job_id of a will_run will_run job prior to creating the
job. Invalidates the jobs for non-slurmuser jobs. Also not burning a
jobid could make the will_run job not be distinguishable in the logs.

Will handle the federation aspect of this in 17.11.

Bug 3436

job_write_lock and sleep a second before grabbing it again.  This should probably be made
configurable later on.

# Conflicts:
#	src/slurmctld/proc_req.c

e3a7bdcc
f9804256
d72b13f2

Reference bug 3366

If you are running on a Bluegene system we rely on the prolog to take us out of configuring
state.  These commits work good for system rebooting the nodes where the prolog is running,
but in the case of Bluegene this is the opposite desire :).   These commits on a Bluegene
pretty much make it so a batch job never gets launched.

Properly set SLURM_JOB_GPUS environment variable for Prolog.
bug 3437

Clear job's reason of "BeginTime" in a more timely fashion and/or prevents
    them from being stuck in a PENDING state. There are multiple ways of
    clearing the reason, especially on a lightly loaded system, but the
    state can persist indefinitely on a heavily loaded system.
bug 3368

Fix to logic for getting expected start time of existing job ID with
    explicit begin time that is in the past. Previous logic would
    compare that (past) begin time with advanced reservations that
    would compete with it rather than the current time.

On cray systems with step NHC, the step launches are delayed and
  produce a pair of messages (below) that caused the test to fail:
  srun: Job step creation temporarily disabled, retrying
  srun: Job step created

The v17.02 updates appear to have only gone into master rather than
  the slurm-17.02 branch

CRAY systems only: TaskPlugins must list task/cgroup before task/cray in
    order for the cgroup files to be created before task/cray runs. Without
    this change, the task/cray plugin frequently produces errors about the
    "mems" file being missing. The errors don't seem consistent, so this
    probably involves a race condition. Note that NERSC uses this order
    today and I changed read_config.c to produce a fatal error if the order
    is reversed.

Failure to do so results in a bunch of task/cray errors about
  not finding the cgroup set up.