This results in an out-of-bounds access (if control_machine was not
being intentionally over-alloced to avoid it), the wrong address,
and other subtle problems.

C's order of operations meant this was resolving as:
i = (_backup_index() != -1);
which is either 0 or 1.

Through sheer luck, this still results in the correct answer for the primary
(_backup_index() is -1, and then i = (-1 != -1) is still 0 which is correct),
and first backup controller (_backup_index() is 1, and then i = (1 != -1) is
still 1 which is also correct), but any further backups controllers will end
up with the address of the first backup.

Use the already-established slurmctld_primary bool instead.

The second NULL check is a duplicate of the first.

The first check is also unnecessary - this field existing is managed by
the control_cnt variable. (At one point in development control_cnt did not
exist, and control_machine was a 0-terminated array instead.)

Otherwise cross-architecture failover will break in confusing ways.

Bug 5256.

plugin.

Bug 5583

Caught by verify_lock() annotation in job_submit_plugin_modify().

Bug 5578.

Caught by verify_lock() annotations in validate_job_create_req()
and job_allocate() respectively.

Bug 5578.

Brian approved

Brian approved

Brian approved

This is only to quite coverity.  I don't think this is a real problem.

Brian approved.

Fix coverity 187747

(i.e. gres=gpu/tesla) it would get a count of 0.

Bug 5570

Note that pipe2() is Linux-specific, but this whole cgroup plugin is
already Linux-specific in design, and the eventfd() call itself is
Linux-specific as well.

Bug 5570.

Didn't realize centos 6 was so far behind.

Bug5503

"IN" tres_usage is reads
"OUT" tres_usage is writes

page faults are only "ins"

In 18.08 the jobacct_info stats were changed to tres_usage arrays which
are init'ed to INFINITE64 but < 18.08 it was init'ed to 0's.

Bug 5554

In 18.08, usage values are stored as bytes but in <18.08 values were
stored in KB, MB, etc.

Also handle cputime adjustments. Related commit: efc161ef.

In 18.08, VMSIZE is stored as bytes and not kilos anymore.

Related commit: c9448c80

Since cputime isn't stored a double anymore, but as a uin64_t, the
cputime is adjusted so that precision isn't lost.

Related commit: efc161ef

In 18.08, the stats are stored in TRES arrays and uses the
slurmdb_find_tres_count_in_string() function to return the TRES value.
If a value doesn't exist, the function returns INFINITE64. But < 18.08
is expecting NO_VAL values.

e.g.
A TRES position of INFINTE caused a lappy0 node to be shown -- I don't
have a lappy0.
brian@lappy:~/slurm/master/lappy$ sacct -j 232809 -o MaxVMSizeNode
 MaxVMSizeNode
--------------

        lappy0

In 18.08, the usage is stored in a TRES arrays and uses the
slurmdb_find_tres_count_in_string() function to return the TRES value.
If a value doesn't exist, the function returns INFINITE64. But < 18.08
is expecting NO_VAL values.

Turns out if you don't close up everything you open the hdf5 lib doesn't
like that.

Fixs regression in 011b2f23.

Alphabetize target list while here.

Bug 4918