If a job step request comes in while the slurm prolog is running,
slurmd will happily launch the job step. This means that a user
could run code before the prolog is complete, which could cause
strange errors or in some cases a security issue. Instead return
an error (EINPROGRESS for now) and do not allow job steps to run
during prolog.

Create a new function, _prolog_is_running(), to determine if a job
prolog is currently running from within slurmd, and use this new
function in place of list_find_first in _wait_for_job_running_prolog.

Some cgroup code would retry continuously if somehow a cgroup
didn't exist when xcgroup_delete() was called (See for instance
proctrack/cgroup's slurm_container_plugin_wait()). To fix this
for all callers, return SUCCESS from xcgroup_delete() if rmdir(2)
return ENOENT, since the cgroup is already deleted.

Test of gres.conf configurations options
test 913

Add association usage information to "scontrol show cache" command output.

Dear all,

we noticed that debugX() and error() calls in srun mess up the output if the --pty flag is used. The reason for this behavior is that srun sets the terminal in raw mode and disables output processing. This is fine for the output forwarded from the remote damon but not for local printf()s by the srun process. This problem can be circumented by re-enabling OPOST after the cfmakeraw() call in srun(). A patch is pasted at the bottom of the mail. It works nicely on Linux but I am not 100% sure it may not have some undesirable side effects on other platforms.

Best regards,
Dorian

Example with current HEAD:

[snip]
srun: jobid 10: nodes(1):`node1', cpu counts: 1(x1)
srun: launching 10.0 on host node1, 1 tasks: 0
                                              srun: route default plugin loaded
                                                                               srun: Node node1, 1 tasks started
                                                                                                                srun: Received task exit notification for 1 task (status=0x0100).
                                         srun: error: node1: task 0: Exited with exit code 1
                                                                                            #
Example with the patch applied:

[snip]
 srun: jobid 11: nodes(1):`node1', cpu counts: 1(x1)
srun: launching 11.0 on host node1, 1 tasks: 0
srun: route default plugin loaded
srun: Node node1, 1 tasks started
srun: Received task exit notification for 1 task (status=0x0100).
srun: error: node1: task 0: Exited with exit code 1

Add job, step and reservation TRES information to sview command

Prevent test failure if the compute node does not permit user
  control over CPU frequency (no "userspace" governor).

When submitting a job with srun -n# the job may be allocated more than # because
the job was given the whole core or socket (eg. CR_CORE, CR_SOCKET). sacct
showed only what the step used and not the allocation. This commit shows the job
and the step if job and step cpus are different.

man page.

Major re-write of the sreport command to support --tres job option
and permit users to select specific tracable resources to generate
reports for. For most reports, each TRES is listed on a separate
line of output with its name. The default TRES type is "cpu" to
minimize changes to output.

556c4ace

Bug 1745

This reverts commit 3f91f4b2.

and test21.* updated to use them.

Bug 1745

Add parrtition information to sshare output

The regression tests were looking for TrackWCKey=YES, but the
  current output value is numeric (TrackWCKey=1). Correcting
  this results in test22.1 failing. In fact, the test has not
  run since the format of TrackWCKey changed.

logic was generating invalid size unpack error