Ticket 23337 - sacctmgr show event actually does not print draining nodes
Summary: sacctmgr show event actually does not print draining nodes
Status: RESOLVED FIXED
Alias: None
Product: Slurm
Classification: Unclassified
Component: Documentation (show other tickets)
Version: 24.11.6
Hardware: Linux Linux
: 4 - Minor Issue
Assignee: Ricard Zarco Badia
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2025-07-29 00:53 MDT by Ole.H.Nielsen@fysik.dtu.dk
Modified: 2025-08-01 11:16 MDT (History)
3 users (show)

See Also:
Site: DTU Physics
Slinky Site: ---
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
Google sites: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
NoveTech Sites: ---
Nvidia HWinf-CS Sites: ---
OCF Sites: ---
Recursion Pharma Sites: ---
SFW Sites: ---
SNIC sites: ---
Tzag Elita Sites: ---
Linux Distro: ---
Machine Name:
CLE Version:
Version Fixed: 25.05.2 25.11
Target Release: ---
DevPrio: ---
Emory-Cloud Sites: ---


Attachments

Note You need to log in before you can comment on or make changes to this ticket.
Description Ole.H.Nielsen@fysik.dtu.dk 2025-07-29 00:53:54 MDT
The slurm-users mailing list has a discussion of the command "sacctmgr show event where node=<nodename>" for listing node events.  This is an *extremely useful* command!

However, the sacctmgr documentation[1] seems to be slightly incorrect when stating:

event: Events like downed or draining nodes on clusters. 

As pointed out in the mailing list: Be aware that down and drainED nodes are there, but not drainING. 

Can you please reformulate the documentation so that the precise behavior is given?

IMHO, having the state "Draining" from the database would also be very useful, if it actually gets recorded.  Can you kindly clarify this possibility?

Thanks a lot,
Ole

[1] https://slurm.schedmd.com/sacctmgr.html#OPT_event
Comment 1 Ricard Zarco Badia 2025-07-29 04:09:21 MDT
Hello Ole,

I have done some quick tests to make sure and yes, the DB only gets populated with the event once the node actually finishes up draining.

>> IMHO, having the state "Draining" from the database would also be very useful, 
>> if it actually gets recorded.  Can you kindly clarify this possibility?

I cannot comment on that *yet*. I would need to discuss this internally first. I will let you know when I have some feedback.

Best regards, Ricard.
Comment 2 Ole.H.Nielsen@fysik.dtu.dk 2025-07-29 04:29:37 MDT
Hi Ricard,

(In reply to Ricard Zarco Badia from comment #1)
> I have done some quick tests to make sure and yes, the DB only gets
> populated with the event once the node actually finishes up draining.
> 
> >> IMHO, having the state "Draining" from the database would also be very useful, 
> >> if it actually gets recorded.  Can you kindly clarify this possibility?
> 
> I cannot comment on that *yet*. I would need to discuss this internally
> first. I will let you know when I have some feedback.

Thanks for confirming this.

In the meantime, would you be able to work on updating the documentation[1]?

Thanks,
Ole
Comment 5 Ricard Zarco Badia 2025-07-30 04:01:54 MDT
Hello Ole,

>> In the meantime, would you be able to work on updating the documentation?

Sure, I have proposed some changes to be reviewed. I will let you know as soon as I have any news.

And coming back to this:

>> IMHO, having the state "Draining" from the database would also be very useful, 
>> if it actually gets recorded.  Can you kindly clarify this possibility?

We did some digging and found out that we already have an enhancement request for this. I cannot say when/if/how it will be done, but this is present in our development backlog.

Best regards, Ricard.
Comment 6 Ricard Zarco Badia 2025-08-01 11:16:43 MDT
Hello Ole,

We have added the following documentation changes in this commit [1]. It is not in the web page yet, but it will be there as soon as we push a new version of the docs.

I think this covers all right now, I will be closing the ticket. Please feel free to reopen and reply if necessary.

Best regards, Ricard.

[1] https://github.com/SchedMD/slurm/commit/2c115fd5e1e4b9261128e398a79a65cb4f38e05a