[slurm-users] AuthInfo broken in 25.05.1 ?

[michael--- via slurm-users]

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.

--
slurm-users mailing list -- slurm...@lists.schedmd.com
To unsubscribe send an email to slurm-us...@lists.schedmd.com

[michael--- via slurm-users]

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)
---

[Ole Holm Nielsen via slurm-users]

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

[Tim Wickberg via slurm-users]

> 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

--
Tim Wickberg
Chief Technology Officer, SchedMD LLC
Commercial Slurm Development and Support