Ticket 24010 - sacctmgr dump clustername prints unwarranted information to stderr
Summary: sacctmgr dump clustername prints unwarranted information to stderr
Status: OPEN
Alias: None
Product: Slurm
Classification: Unclassified
Component: User Commands (show other tickets)
Version: 25.05.4
Hardware: Linux Linux
: 4 - Minor Issue
Assignee: mckay@schedmd.com
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2025-10-31 01:23 MDT by Ole.H.Nielsen@fysik.dtu.dk
Modified: 2025-11-03 15:24 MST (History)
0 users

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:
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 Ole.H.Nielsen@fysik.dtu.dk 2025-10-31 01:23:22 MDT 
Besides daily database dumps, we have started dumping also the associations etc. using "sacctmgr dump clustername" to have complete backups.

Unfortunately, the "sacctmgr dump" command prints an unwarranted copy of the dump information to stderr, besides creating the expected dump file.  This is what we get:

$ sacctmgr --quiet dump niflheim 
 No filename given, using ./niflheim.cfg.
sacctmgr: QOS - 'normal':Description='Normal QOS default':Priority=25
QOS - 'high':Description='high':Flags='DenyOnLimit':MaxTRESPerJob=cpu=1000:MaxTRESPerUser=cpu=1000:MaxWallDurationPerJob=600:Priority=50
QOS - 'devel':Description='devel':Flags='DenyOnLimit':MaxTRESPerUser=cpu=800,gres/gpu=8:MaxWallDurationPerJob=180:Priority=100
Cluster - 'niflheim':Fairshare=1:QOS='normal'
sacctmgr: Parent - 'root'
(lots of lines deleted)

There doesn't seem to be any good reason to print a duplicate of the dump file to stderr.

Can you please make a fix to suppress this?

Thanks a lot,
Ole
Comment 1 mckay@schedmd.com 2025-11-03 15:24:05 MST 
Hello Ole,

I see the behavior you're talking about and we're discussing the best way forward.

I'll let you know what's decided.

Thanks!
McKay