We are using a non-default AuthInfo configuration and based on
log-messages we see I believe this is not properly handled in certain
parts of the code.

Typical log message:
Aug 12 17:06:15 t02n20 slurmd[27001]: error: Munge encode failed:
Failed to access "/var/run/munge/munge.socket.2": No such file or
directory
Aug 12 17:06:15 t02n20 slurmd[27001]: error: Creating authentication
credential: Socket communication error
Aug 12 17:06:15 t02n20 slurmd[27001]: error: stepd_connect to 3165.0
failed: Protocol authentication error
Aug 12 17:06:15 t02n20 slurmd[27001]: error: If munged is up, restart
with --num-threads=10

Unfortunately the reservation's core_bitmap is a global bitmap and the nodes
in the system may have changed in terms of their node count or nodes have been
added or removed. Make best effort to rebuild the reservation's core_bitmap
on the limited information currently available. The specific cores might
change, but this logic at least leaves their count constant and uses the
same nodes
bug 1850

This propagates the logic from commit aa81c550
into another place where the job CONFIGURING flag is set.

Bug 1770

Bug 1770
Prevent segfaults and return reservation with NULL partition.

Bug 1770
Continuation of ad8279d010.
Add custom typemaps that free pointer after it has been copied onto the stack.

Bug 1770
Just return the static memory, it's not going to increase.

thing (-F exclusive) instead of -F share.

bug 1849

Fix scheduling anomaly with job arrays submitted to multiple partitions,
    jobs could be started out of priority order.
bug 1892

portion of a job array is pending after it's initial start in the
database it could create another row for the remain array instead
of using the already existing row.

bug 1840

opposite.

Fix segfault in Bluegene setups where RebootQOSList is defined in bluegene.conf and accounting is not setup.

Read in correct number of nodes from SLURM_HOSTFILE when specifying nodes and --distribution=arbitrary.

Bug 1808

From eee63695

Bug 1810

No change in functionality

If node definitions in slurm.conf are spread across multiple lines
and topology/tree is configured, then sub-optimal node selection can
occur.
bug 1645

Rather than generating loads of log messages about too much time
being used to build the job queue every few seconds, log it only
every 10 minutes.
bug 1827

Log the number of job-partition pairs added to the queue for job
scheduling.
bug 1827

Previously only batch job completions were being captured.
bug 1820

This patch provides a rewrite of how /proc/cpuinfo is parsed in common_jag.c, as the original code made the incorrect assumption that cpuinfo follows a sane format across architectures ;-)

The motivation for this patch is that the original code was producing stack smashing on a POWER7 running RHEL6.4 Red Hat adds -fstack-protector along with a lot of other protective CFLAGS when building RPMs. The code ran okay with -fno-stack-protector, but that is not the best work-around.

So, the relevant /proc/cpuinfo line on an Intel (Xeon X5675) system looks like:

cpu MHz                : 3066.915

Whereas the relevant line in a POWER7 system is

clock                : 3550.000000MHz

My patch replaces the assumption that the relevant number starts 11 characters into the string with another assumption: That the relevant number starts two characters after a colon in a string that matches (M|G)Hz.

All in all, the function has a few more calls, which may be a performance issue if it has to be called multiple times, but since the section I edited only gets evaluated if we don't know the cpu frequency, getting it right will actually result in fewer string operations and unnecessary opens of /proc/cpuinfo for systems likewise affected.

Finally, I also read the actual value into a double and multiply it up to the size indicated by the suffix, so we end up with KHz? It was unclear what the original code intended, since it matched both MHz and GHz, replaced the decimal point with a zero, and read the result as an int.

--
Chandler Wilkerson
Center for Research Computing
Rice University

This reverts commit 2c95e2d2.

Conflicts:
	src/plugins/select/alps/basil_interface.c

This is related to bug 1822.  It isn't clear why the code was taken out in
this commit in the first place and based off of commit 2e2de6a4 (which is
the reason for the conflict) we tried unsuccessfully to put it back.

It appears the only difference here is the addition of
always setting mppnppn = 1 instead of always to
job_ptr->details->ntasks_per_node when no ntasks is set.

This appears to only be an issue with salloc or sbatch as ntasks
is always set for srun.