On Sep 26, 2024, at 9:12 AM, James Wood via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Since upgrading to 3.2.6 we're seeing an issue where the radiusd program just "dies" and stops receiving/handling requests, yet the program itself is still running, has a PID, and netstat shows it's still listening on the ports.
I can see the requests still reaching the machine via tcpdump but nothing from radiusd.
We're using TLS to support EAP connections but no clients are using TLS on this particular server so it's all UDP, though TLS is still enabled and listening. OpenSSL version is 3.0.2
I've included some logs from what little I know about gdb and wondered if anyone can advise the likely culprit of the issue.
The last entries in radius.log were normal authentications and then it just died and stopped receiving requests. I've also observed the same in debug mode, nothing is showing untoward in the output on screen before it dies
Hmm..
(gdb) bt
#0 futex_wait (private=0, expected=2, futex_word=0x572a56ee9c88) at ../sysdeps/nptl/futex-internal.h:146 #1 __GI___lll_lock_wait (futex=futex@entry=0x572a56ee9c88, private=0) at ./nptl/lowlevellock.c:49 #2 0x00007fc3d5098002 in lll_mutex_lock_optimized (mutex=0x572a56ee9c88) at ./nptl/pthread_mutex_lock.c:48 #3 ___pthread_mutex_lock (mutex=mutex@entry=0x572a56ee9c88) at ./nptl/pthread_mutex_lock.c:93 #4 0x0000572a546bfc05 in tls_socket_recv (listener=0x572a56e6f710) at src/main/tls_listen.c:476
The code I have for 3.2.6 doesn't have any call to proxy_mutex_lock at line 476 of tls_listen.c That being said, it looks like there are a few cases where the function may return without an unlock. I've pushed a patch. Alan DeKok.