I found today that SIGTERM'ed jobs show as OOM'ed in the database today.
From this commit:
commit 2a75b72d
A job terminating with SIG_TERM (and others) will incorrectly report
the job termination state as Out Of Memory.

# Conflicts:
#	src/slurmctld/acct_policy.c

Association.

This reverts commits 92d2c645 and 37be42ec.  This caused incorrect
behavior, original code was correct.  This also corrects documentation additions
in commit 4cfe6bde.

This code caused the first clause never to be correct and if you were
over the limit you would get the third clause reporting a huge number available
where it should be a negative number.  The reality is the first clause should
had been triggered and handled correctly.

This reverts commit af52111c.

Association.

This reverts commits 92d2c645 and 37be42ec.  This caused incorrect
behavior, original code was correct.  This also corrects documentation additions
in commit 4cfe6bde.

This code caused the first clause never to be correct and if you were
over the limit you would get the third clause reporting a huge number available
where it should be a negative number.  The reality is the first clause should
had been triggered and handled correctly.

conversion process easier.

a SUM of the steps to the job table.

What this does is removes the join on the step table during rollups.  It turns
out this was a very costly join if the tables were fairly large.

We can now just grab the data directly from the job_table which already contains
the data in the tres_alloc column.

at the end of a job.

We use the last step in the allocation (works for everything but salloc) to
get the data to the job.  We update the job as steps finish and send a new
tres_alloc_str to the database which will update the job record with the info.

We could not use the job_comp message for anything but an salloc since there
is not guarantee it will get there after the last step does.

to report the end about of energy used by all steps.  It is not to be used to
evaluate limits at the moment.  If so we would need to change this.  As this
wasn't a thing when this was written we felt this was the easiest way to get
the total energy for the job.

the tres_alloc_str on a job at the end, dealing with energy.

function (_set_tres_alloc_str) to always get locks correct.

when there was only one job_table for all clusters where there was potential
for a job to start on multiple clusters at the same time it was needed to
differentiate one job from another.  Since this hasn't been the case for many
years we are removing it as we really should only need job_id and time_submit
to make it unique.

which will be changing it's unique index in a following commit.

NO_VAL values to NO_VAL64 on it.

system.

What this patch does is looks at the partition the job is running in to get
the cpus per node off the first node in the partition.  Before it would
just look at the first node on the system which isn't that great on a
heterogeneous system.

Bug 3486

Still use the conf pointer, rather than rewriting the following lines,
but set it directly to &slurmctld_conf.

slurm_conf_lock() returns &slurmctld_conf (with added locking).
Avoid the additional function call and refernce the variable directly.

Locking the conf is already handled within slurmctld by lock_slurmctld,
and locations within slurmcltd changing slurmctld_conf don't grab the separate
slurm_conf_lock() mutex anyways.

Don't look it up again; this also removes a call to slurm_conf_lock().