Ticket 1293 - Multiple clusters, Slurmdbd and uids
Summary: Multiple clusters, Slurmdbd and uids
Status: RESOLVED INFOGIVEN
Alias: None
Product: Slurm
Classification: Unclassified
Component: slurmdbd (show other tickets)
Version: 14.03.9
Hardware: Linux Linux
: 5 - Enhancement
Assignee: David Bigagli
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2014-12-03 23:22 MST by Marco Passerini
Modified: 2014-12-05 01:41 MST (History)
2 users (show)

See Also:
Site: CSC - IT Center for Science
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

Note You need to log in before you can comment on or make changes to this ticket.
Description Marco Passerini 2014-12-03 23:22:57 MST
Hi,

I'm not sure whether this is a bug of a feature, I would like to notify that I have been setting up a multicluster configuration with one slurmdbd, and when I tried to connect to slurmdbd with the second cluster I got this kind of error:

[2014-12-03T16:39:41.420] Running as primary controller
[2014-12-03T16:39:41.420] Registering slurmctld at port 6817 with slurmdbd.
[2014-12-03T16:39:41.461] debug:  slurmdbd: DBD_RC is 2002 from DBD_FLUSH_JOBS(1408): DBD_FLUSH_JOBS message from invalid uid
[2014-12-03T16:39:41.461] slurmdbd: reopening connection
[2014-12-03T16:39:41.462] debug:  slurmdbd: Sent DbdInit msg
[2014-12-03T16:39:41.503] error: slurmdbd: Issue with call DBD_REGISTER_CTLD(1434): 2002(DBD_REGISTER_CTLD message from invalid uid)
[2014-12-03T16:39:41.503] fatal: You need to add this cluster to accounting if you want to enforce associations, or no jobs will ever run.

So I decided to change the UID number to which the slurm user is assigned on the secondary cluster so that it would be the same as on the first cluster, and then everything worked correctly.
This is probably just an annoyance, but it would be nice if the UID number didn't matter. Just a tip for a future release :)
Comment 1 Moe Jette 2014-12-04 02:11:55 MST
Slurm authentication is based upon Munge and Munge is UID/GID based, so to address this issue, the Munge infrastructure would need to change first.
Comment 2 Marco Passerini 2014-12-04 18:23:50 MST
Ok, thank you for the quick answer.
Comment 3 Moe Jette 2014-12-05 01:41:46 MST
(In reply to Marco Passerini from comment #2)
> Ok, thank you for the quick answer.