Correction to hostlist sorting for hostnames that contain two numeric
components and the first numeric component has various sizes (e.g.
"rack9blade1" should come before "rack10blade1")

job on future step creation attempts.

also cause it to run if the realtime server ever goes away.

Especially for newly started jobs, the PrologSlurmctld can change
a job's QOS based upon resource allocation.

DB2 so hard.

on them.  This should only happen in extreme conditions.

with associations get the deleted associations as well.

request resources that reach a 'Max' limit.

user mark the state canceled instead of completed.

so it gets sent again.  This isn't a major problem since the start will
happen when the job ends, but this does make things cleaner.

you query against that with -N and -E you will get all jobs during that
time instead of only the ones running on -N.

Signed-off-by: Danny Auble <da@schedmd.com>

was already in error and isn't deallocating and underlying hardware goes
bad one could get overlapping blocks in error making the code assert when
a new job request comes in.

overcommit.

overcommit.

Previously only requeued the job once

where needed)

Otherwise an aborted slurmstepd can cause the srun process to hang
indefinitely; a problem reported in trouble ticket 149.

introduce step accounting for a Cray.

This is needed if the munge deamon is under very heavy load
(e.g. with 1000 slurmd daemons per compute node).

slurmctld restart.

Modify sbast logic to continue when slurmd daemon restarts

Previously a file transmission in progress would be aborted when
any of the slurmd daemons restarted. Now it reconnects, revalidates
the credential, and resumes file transmission.

allocation.

NOTE: If you were setting the environment variable SLURMSTEPD_OOM_ADJ=-17,
it should be set to -1000 for Linux 2.6.36 kernel or later.

Signed-off-by: Danny Auble <da@schedmd.com>

aprun process instead of a perl script.

the attached patch changes the default timestamp format in logfiles to conform to RFC 5424 (the current version of the syslog RFC). It is identical to the current default "ISO 8601" timestamp used by slurm, with the exception that the timezone offset is appended. This has the benefits of

1) It's unambiguous.

2) Avoids potential confusion for admins running cluster(s) in different timezones.

3) Might help debug issues related to DST transitions. (More on that later..)

(To be pedantic, a RFC 5424 timestamp is still a valid ISO 8601 timestamp, but the converse is not necessarily true. So there is RFC 3339 which is a "profile" of ISO 8601, that is a subset, recommended for internet protocols. The RFC 5424 timestamp, in turn, is a subset of the RFC 3339 timestamps.)

The previous behavior of can be used by running configure with the

--disable-rfc5424time

flag.