Spare threads not exiting

Matt Ezell matt at
Thu Mar 8 02:41:04 CET 2012


I was originally running FreeRADIUS 2.1.10 that came with CentOS 6.2,
but I've since compiled my own 2.1.12.  It looks like the thread
management isn't quite working like I expect it to.  If I flood the
server with a ton of concurrent requests, it will spawn new threads up
to "max_servers".  Then, if I slowly hit the server with requests (to
allow the cleanup mechanism time to work), the number of threads does
not go down to "max_spare_servers".  Has anyone else seen this?

I instrumented threads.c, and it appears that a thread's "request"
field doesn't get set to NULL after it handles a requests*.  This is a
problem, because the thread reaper uses the condition (handle->request
== NULL) to mark a thread as THREAD_CANCELLED.

I tested a small patch that appears to allow threads to cleanup, but
I'm not sure if it's the right way to proceed with this.  I tried to
setup a pull request on github, but it looks like it tired to push my
entire 2.1.x branch onto master

I understand that you normally request that people provide the output
of "radiusd -X", but "single server" mode handles threading
differently (i.e. I don't see the problem).  Basically, I'm using the
default "thread pool" settings, but all my requests go through an
rlm_perl "authorize" module that sets Auth-Type to 'Accept' (for
testing).  Let me know if you still want this output to see some of my

I also understand that some of this code has been re-worked for
MASTER.  I understand if you don't plan on releasing another 2.1.x,
but I would appreciate it if you let me know if this is an appropriate
fix on 2.1.x.  We are probably going to stick with this series for a

Thanks for your time-

* I added the following code in threads.c in thread_pool_manage()

if (handle->request != NULL) {
  DEBUG2("Threads: thread %d NOT canceled, processing

More information about the Freeradius-Devel mailing list