Ticket 6697 - sacct -j "$JOBID" requires a start time for older jobs
Summary: sacct -j "$JOBID" requires a start time for older jobs
Status: RESOLVED FIXED
Alias: None
Product: Slurm
Classification: Unclassified
Component: Accounting (show other tickets)
Version: 18.08.6
Hardware: Linux Linux
: --- 4 - Minor Issue
Assignee: Albert Gil
QA Contact:
URL:
: 6755 6830 7046 (view as ticket list)
Depends on:
Blocks:
 
Reported: 2019-03-14 12:34 MDT by Chris Samuel (NERSC)
Modified: 2019-05-17 09:38 MDT (History)
3 users (show)

See Also:
Site: NERSC
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
OCF Sites: ---
Recursion Pharma Sites: ---
SFW Sites: ---
SNIC sites: ---
Linux Distro: ---
Machine Name:
CLE Version:
Version Fixed: 18.08.7
Target Release: ---
DevPrio: ---
Emory-Cloud Sites: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this ticket.
Description Chris Samuel (NERSC) 2019-03-14 12:34:58 MDT 
Hi there,

One of our staff has just noticed that sacct -j ${OLDER_JOBID} now requires a start time in 18.08.6-2 when before it didn't.

Without:

csamuel@cori12:~> sacct -j 19672721  -X
       JobID    JobName  Partition    Account  AllocCPUS      State ExitCode 
------------ ---------- ---------- ---------- ---------- ---------- -------- 
csamuel@cori12:~>


With:

csamuel@cori12:~> sacct -j 19672721 -S 2019-01-01 -X
       JobID    JobName  Partition    Account  AllocCPUS      State ExitCode 
------------ ---------- ---------- ---------- ---------- ---------- -------- 
19672721     stream-2TB      debug     nstaff       4096  COMPLETED      0:0

The manual page for sacct says:

       -S, --starttime
                 Select  eligible  jobs  in  any state after the specified time. Default is 00:00:00 of the current day, unless the '-s' or '-j' options are used. If the '-s'
                 option is used, then the default is 'now'. If states are given with the '-s' option then only jobs in this state at this time will be returned. If  the  '-j'
                 option is used, then the default time is Unix Epoch 0. See the DEFAULT TIME WINDOW for more details.


as well as:


       WITH --jobs AND WITHOUT --state specified:

              --starttime
                     Dfaults to Epoch 0.

              --endtime
                     Defaults to Now.


So it appears that it should still work.  I wonder if this is an unexpected side effect of this item in NEWS?

 -- Enforce documented default usage start and end times when querying jobs from
    the database.


All the best,
Chris
Comment 2 Broderick Gardner 2019-03-14 13:57:09 MDT 
This looks like a regression introduced by a recent rework of the sacct flag logic. The intent was to more closely and clearly implement what is stated in the documentation, but this particular case is not correct. I'll get this fixed; thanks for reporting it.
Comment 4 Chris Samuel (NERSC) 2019-03-14 14:46:33 MDT 
(In reply to Broderick Gardner from comment #2)

> This looks like a regression introduced by a recent rework of the sacct flag
> logic. The intent was to more closely and clearly implement what is stated
> in the documentation, but this particular case is not correct. I'll get this
> fixed; thanks for reporting it.

Thanks Broderick, much appreciated!

All the best,
Chris
Comment 10 Albert Gil 2019-03-15 11:04:39 MDT 
Hi Chris,

This bug is definitely a regression of bug 5717.
We are already reviewing a patch and improving regression tests (see test12.10).

We'll let you know,
Albert
Comment 20 Albert Gil 2019-03-20 03:24:20 MDT 
Hi Chris,

The patch has been committed in branch slurm-18.08 (3361bf611c61de3bb90f8cadbacf58b4d1dc8707) and it will be added to 18.08.7.

I'm closing this as fixed.
Thanks for reporting it,
Albert
Comment 21 Chris Samuel (NERSC) 2019-03-20 12:00:33 MDT 
(In reply to Albert Gil from comment #20)

> Hi Chris,

Hi Albert,

> The patch has been committed in branch slurm-18.08
> (3361bf611c61de3bb90f8cadbacf58b4d1dc8707) and it will be added to 18.08.7.

Thanks for that - I'm currently trying to automate our builds of Slurm RPMs (we've got to build 3 different sets for the Cray, each with different config options) and so once I've got that working then I'll pull this patch into our build to see if it resolved the issue.


All the best,
Chris
Comment 22 Albert Gil 2019-03-28 12:42:26 MDT 
*** Ticket 6755 has been marked as a duplicate of this ticket. ***
Comment 23 Albert Gil 2019-04-11 02:09:31 MDT 
*** Ticket 6830 has been marked as a duplicate of this ticket. ***
Comment 24 Albert Gil 2019-04-15 08:51:21 MDT 
Hi Chris,

> > The patch has been committed in branch slurm-18.08
> > (3361bf611c61de3bb90f8cadbacf58b4d1dc8707) and it will be added to 18.08.7.
> 
> Thanks for that - I'm currently trying to automate our builds of Slurm RPMs
> (we've got to build 3 different sets for the Cray, each with different
> config options) and so once I've got that working then I'll pull this patch
> into our build to see if it resolved the issue.

As you probably know, 18.08.7 was released last week, mainly to avoid more duplicates of this regression bug.


Albert
Comment 25 Albert Gil 2019-05-17 09:38:27 MDT 
*** Ticket 7046 has been marked as a duplicate of this ticket. ***