Bug 6995

Job steps that run on cloud nodes and use the alias_list - in other
words, SlurmctldParameters=cloud_dns is not in slurm.conf - all talk
directly back to the slurmctld. To make that happen, we set the parent
tank of each stepd to -1. However, we also set the rank of each stepd to
0. this meant that when each stepd sent a REQUEST_STEP_COMPLETE RPC to
the slurmctld, they would tell slurmctld to clean up node 0 in the step
allocation. So, multi-node step allocations weren't cleaning up after
the steps completed and would cause subsequent job steps to hang. The
step allocations would only clean up properly at the end of the job.

Ensure that each stepd uses the correct rank so that job steps are
properly cleaned up after each step completes.

Bug 6467.

They were associated to these two commits:

b4d7de48
6871185a

Bug 5562.

Error reported by CLANG

Cherry pick to 18.08.

Bug 6996.

unlimited could get overwritten with default queue depth preventing the
whole queue from being looked at -- especially in a high-throughput
envrionment.

Bug 6822

Co-authored-by: Morris Jette <jette@schedmd.com>

Node memory overallocation wouldn't be properly detected since we would
just be interpreting the available memory as RealMemory - MemSpecLimit,
ignoring other job's memory usage.

Bug 5562.

This compares a job memory request against each selected node available
memory, interpreting the latter for now as RealMemory - MemSpecLimit.

Bug 5562.

Place all three memory cases (per cpu, per node and all node memory) in
a single loop, since all three cases need to traverse all job_resources
selected nodes. Preparation for a follow-up commit that contains the
real fix.

Bug 5562.

Add handling for acct_gather_energy/xcc and acct_gather_profile/influxdb.

Bug 6829.

This is select/cons_res, not select/cons_tres.

Previous select/cons_res logic would allocate one CPU per task on the node

Bug 6981

There was a syntax error in the mysql for inserting the event records
into the event table caused by commit 3d61b6aa. The syntax error was
a semicolon in the middle of the query, for example:

insert into "voyager_event_table" (time_start, time_end, node_name,
cluster_nodes, reason, reason_uid, state, tres) values ('1538669453',
'1539298628', 'v1', '', 'cold-start', '1017', '0',
'1=8,2=4000,5=8,1001=4,1002=1');, (<... another record>);, ...

Bug 7025.

This commit caused loading usage table archive files to fail.
Specifically, wckey and assoc hourly/daily/monthly usage tables and the
cluster usage tables archive files would all fail to load.

Bug 7025.

It's more suitable for the purpose of checking if a file exists, plus
avoids the unnecessary struct stat variable since we don't care about
the file information.

Continuation of 1e234c3d.

Bug 6033.

Replace strncpy with xstrdup and snprintf with xstrfmtcat respectively
in _make_archive_name. This also fixes a coverity error CID 198462.

Continuation of 1e234c3d.

Bug 6033.

Bug 6033.

If _get_oldest_record() finds a record to archive/purge, then archive
should always archive at least one record. If for whatever reason it
fails to archive any records (_archive_table() returns a 0), then we
don't want call continue, but want to return an error. Calling continue
to go back to the beginning of the while loop would result in an
infinite loop.

Bug 6033.

Bug 6033.

Trying to archive too many records at once can result in archive files
that are too big to read or even too big to be written. Only archive 50k
records at a time, like we only purge 50k records at a time.

Bug 6033.

The time period of the archive file currently depends on submit or start
time and whether the purge period is in hours, days, or months.
Previously, if the archive file name already exists, we would overwrite
the old archive file with the assumption that these are duplicate
records being archived after an archive load. However, that could result
in lost records in a couple of ways:

  * If there were runaway jobs that were part of an old archive file's
  time period and are later fixed and then purged, the old file would
  be overwritten.
  * If jobs or steps are purged but there are still jobs or steps in
  that time period that are pending or running, the pending or running
  jobs and steps won't be purged. When they finish and are purged, the
  old file would be overwritten.

Instead of overwriting the old file, we append a number to the file name
to create a new file. This will also be important in an upcoming commit.

Bug 6033.

It was set but never read.

Bug 6033.

Change a few variables in archiving to use the correct signed or
unsigned type to avoid implicit casting.

Bug 6033.

Bug 6799.

These conflict with JOB_MEM_SET/JOB_RESIZED in 19.05. Since 19.05rc1
has shipped - but no 18.08 maintenance releases have shipped with these
new flags - it is safer to renumber them here to avoid the merge conflict
going into 19.05.

Bug 6064.

When tres_usage_in_max field is empty it is recorded as '' in the database
which leads find_tres_count_in_string() to return an INFINITE64. Seff treats
INIFINITE64 as a valid value. This patch fixes this issue.

Bug 6817

Bug 6880/6952.

Bug 6064

On requeue, the origin cluster job record is copied to submit
to sibling clusters. If the job was originally submitted
to accept cluster default account, partition, etc, those fields
are now filled in on the origin. Here we add flags to indicate
that those fields need to be cleared on resubmission to siblings.
Bug 6064

This is a holdover from when the fed job_info list was added.
The cluster lock has to be cleared from both the job_ptr and
the job_info.
Bug 6064

Blessed by Tim.

when one offset passes and other fails.

Bug 6892

Bug 6513.

Bug 6513

Bug 6513

First offset is good but second is bad -- didn't request task count.

$ cat etc/job_submit.lua
function slurm_job_submit(job_desc, part_list, submit_uid)
        slurm.log_user("submit1\nstuff")
        slurm.log_user("submit2")
        slurm.log_user("submit3")

    -- slurm.log_user("case 0")
    if job_desc.num_tasks == slurm.NO_VAL or job_desc.num_tasks == nil then
        slurm.log_user("Batch submit error:  Must specify either number of nodes or number of tasks!")
        -- reject the job
        return slurm.ERROR
    end

        return slurm.SUCCESS
end

function slurm_job_modify(job_desc, job_rec, part_list, modify_uid)
        slurm.log_user("modify1")
        slurm.log_user("modify2")
        slurm.log_user("modify3")
        return slurm.SUCCESS
end

slurm.log_user("initialized")
return slurm.SUCCESS

$ sbatch -Ablah2 -n1 --wrap="hostname" : -J asdfl
sbatch: error: 0: initialized
sbatch: error: 0: submit1
sbatch: error: 0: stuff
sbatch: error: 0: submit2
sbatch: error: 0: submit3
sbatch: error: submit1
sbatch: error: stuff
sbatch: error: submit2
sbatch: error: submit3
sbatch: error: Batch submit error:  Must specify either number of nodes or number of tasks!
sbatch: error: Batch job submission failed: Unspecified error

$ sbatch -Ablah2 -n1 --wrap="hostname" : -J asdfl
sbatch: error: 0: initialized
sbatch: error: 0: submit1
sbatch: error: 0: stuff
sbatch: error: 0: submit2
sbatch: error: 0: submit3
sbatch: error: 1: submit1
sbatch: error: 1: stuff
sbatch: error: 1: submit2
sbatch: error: 1: submit3
sbatch: error: 1: Batch submit error:  Must specify either number of nodes or number of tasks!
sbatch: error: Batch job submission failed: Unspecified error

srun already handles this

Was dumping this:
$ srun -A test7.21-account.1 --qos test7.21-qos.1 -n5 : -n3 : -n1 /bin/true
srun: error: 0: submit1
srun: error: submit2
srun: error: submit3
srun: error: Unable to allocate resources: Invalid account or account/partition combination specified

Will now dump this:
$ srun -A test7.21-account.1 --qos test7.21-qos.1 -n5 : -n3 : -n1 /bin/true
srun: error: 0: initialized
srun: error: 0: submit1
srun: error: 0: submit2
srun: error: 0: submit3
srun: error: Unable to allocate resources: Invalid account or account/partition combination specified

Bug 6513.

Regression from 70b4e06d.

Bug 6892.

Bug 6895.

Bug 6895

Bug 6895