I am using the AuthInfo in both slurm.conf and slurmdbd.conf to point to a different location for the munge socket.
This works as expected in slurmdbd, but it does not work for slurmctld. In slurmctld it seems to ignore this setting and try to locate the munge socket at the default location and then fail.
When using the same approach in 23.11.11, for example, AuthInfo is working as expected for both slurmctld and slurmdbd.
Sample config from slurm.conf and slurmdbd.conf
AuthType=auth/munge AuthInfo=socket=/my/non-default/location/of/munge.socket
I'd be grateful for any pointer whether this is a genuine bug/regression or not.
Many thanks,
Michael.
Upon further investigation I found that my testing above was a bit flawed and there is a general issue with the AuthInfo information not properly read. The below patch fixes this issue and I can configure the munge sockets to whatever I desire.
Maybe I should send this to slurn-dev ?
--- index c33782167a..1568742481 100644 --- a/src/interfaces/auth.c +++ b/src/interfaces/auth.c @@ -335,14 +335,18 @@ void *auth_g_create(int index, char *auth_info, uid_t r_uid, void *data, int dlen) { cred_wrapper_t *cred; + char *info = auth_info;
xassert(g_context_num > 0);
if (r_uid == SLURM_AUTH_NOBODY) return NULL;
+ if (!info) + info = slurm_conf.authinfo; + slurm_rwlock_rdlock(&context_lock); - cred = (*(ops[index].create))(auth_info, r_uid, data, dlen); + cred = (*(ops[index].create))(info, r_uid, data, dlen); slurm_rwlock_unlock(&context_lock);
if (cred) ---
Hi Michael,
On 10/27/25 08:35, michael--- via slurm-users wrote:
Upon further investigation I found that my testing above was a bit flawed and there is a general issue with the AuthInfo information not properly read. The below patch fixes this issue and I can configure the munge sockets to whatever I desire.
It's great that you found the root cause and made a fix to the Slurm source! Is this a regression in 25.05?
Maybe I should send this to slurn-dev ?
The Slurm developers and support at SchedMD will only consider patches from their paying customers, and only consider non-customers in exceptional cases. Therefore your patch may have a hard time getting attention.
I suggest that you file a ticket at https://support.schedmd.com/ describing your updated testing and attaching your patch. Then you can send a link to the ticket in this thread. Maybe one of the paying SchedMD customers will take an interest in your patch and ask Slurm support to consider it.
Thanks, Ole
The Slurm developers and support at SchedMD will only consider patches from their paying customers, and only consider non-customers in exceptional cases. Therefore your patch may have a hard time getting attention.
One clarification - SchedMD does look at contributions from everyone. Our contributing guide describes the process:
https://gitlab.com/SchedMD/dev/slurm/-/blob/master/CONTRIBUTING.md
I'll admit that there are a lot of submissions that I don't respond to publicly after initial triage. This is usually as the patch is either overly specific to the submitter's own system, or isn't addressing the issue appropriately.
The notable difference in routing between customer-submitted patches and community contributions is that I will usually redirect patches back to support for further discussion and triage.
- Tim
-
michael＠mayer.cx -
Ole Holm Nielsen -
Tim Wickberg