to be that way.

Conflicts:
	Makefile.in
	auxdir/Makefile.in
	configure
	contribs/Makefile.in
	contribs/arrayrun/Makefile.in
	contribs/cray/Makefile.in
	contribs/lua/Makefile.in
	contribs/pam/Makefile.in
	contribs/perlapi/Makefile.in
	contribs/perlapi/libslurm/Makefile.in
	contribs/perlapi/libslurmdb/Makefile.in
	contribs/phpext/Makefile.in
	contribs/sjobexit/Makefile.in
	contribs/slurmdb-direct/Makefile.in
	contribs/torque/Makefile.in
	doc/Makefile.in
	doc/html/Makefile.in
	doc/man/Makefile.in
	etc/init.d.slurm
	src/Makefile.in
	src/api/Makefile.in
	src/common/Makefile.in
	src/database/Makefile.in
	src/db_api/Makefile.in
	src/plugins/Makefile.in
	src/plugins/accounting_storage/Makefile.in
	src/plugins/accounting_storage/common/Makefile.in
	src/plugins/accounting_storage/filetxt/Makefile.in
	src/plugins/accounting_storage/mysql/Makefile.in
	src/plugins/accounting_storage/none/Makefile.in
	src/plugins/accounting_storage/pgsql/Makefile.in
	src/plugins/accounting_storage/slurmdbd/Makefile.in
	src/plu...

Fixes a bunch of warnings of this type
warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body

In current version of slurm initscript, a stop action returns a
non null exit code as slurmstatus exit code is directly used and
the daemons are stopped.
Ensure that when called from slurmstop, slurmstatus error code is
reversed to correctly match the attended error code of the stop
stage.
Port of v2.4 commit a09bffa5
Matthieu Hautreux authored 3 months ag

Patch from Aleksej Saushev.

and that system had a smaller prefix than dimensions and only had one
node.  (i.e. bgq0000 would fall into this clause)  The dimensions in the
cluster_rec would not be set up correctly if this was the case.

CnodeCount/CnodeErrCount so to point out there are cnodes in an error state
on the block.  Draining the block and having it reboot when all jobs are
gone will clear up the cnodes in Software Failure.

for a long time after the SLURM job has been flushed from the system
we don't have to worry about rebooting the block to sync the system.

process when job is killed by scancel.

expired.

software error before.

updates.

state when already in error state.

sub-allocation steps of sub-block jobs.

blocks.

than your allocation.

are full allocation jobs, and others that are smaller.

Conflicts:
	src/slurmctld/node_scheduler.c

c0a7a7a4

fixed the problem

while jobs are running on them.

is a convenience function in BSD and glibc that internally calls
the equivalent of

    int masterfd = open("/dev/ptmx", flags);
    grantpt (masterfd);
    unlockpt (masterfd);
    int slavefd = open (slave, O_RDRW|O_NOCTTY);

(in psuedocode)

On Linux, with some combinations of glibc/kernel (in this
case glibc-2.14/Linux-3.1), the equivalent of grantpt(3) was failing
in slurmstepd with EPERM, because the allocated pty was getting
root ownership instead of the user running the slurm job.

From the POSIX description of grantpt:

 "The grantpt() function shall change the mode and ownership of the
  slave pseudo-terminal device... The user ID of the slave shall
  be set to the real UID of the calling process..."

 http://pubs.opengroup.org/onlinepubs/007904875/functions/grantpt.html

This means that for POSIX-compliance, the real user id of slurmstepd
must be the user executing the SLURM job at the time openpty(3) is
called. Unfortunately, the real user id of slurmstepd at this
point is still root, and only the effective uid is set to the user.

This patch is a work-around that uses the (non-portable) setresuid(2)
system call to reset the real and effective uids of the slurmstepd
process to the job user, but keep the saved uid of root. Then after
the openpty(3) call, the previous credentials are reestablished
using the same call.