Meyers, Dan wrote:
Ran fine for a week or so, but in the last few days we've had it crash twice, both times with the same message. The logs initially fill with messages of the sort:
"Sat Jul 24 01:05:08 2010 : Error: WARNING: Unresponsive child for request 128145, in module perl component accounting"
Oops.
We'll end up with 32 of the former type of error message (we're currently running with 32 threads configured in the thread_pool in radius.conf), interspersed with the latter, then a stack of the latter type of error (Always for the same set of requests, i.e. one of the ones we got an initial error for, but we'll get the second error multiple times for a given request). Then eventually we get
"Sat Jul 24 01:05:27 2010 : Error: ASSERT FAILED threads.c[406]: (*request)->magic == REQUEST_MAGIC"
That looks like a bug which will be fixed in 2.1.10. See http://git.freeradius.org, branch v2.1.x. Download that and install it. It should fix the problem. If so, please say so.
All our accounting module does in perl is convert the incoming radius hash to yaml and then attempt to write it to a database with a timestamp. I am strongly suspecting that the initial problem is to do with threading in combination with the DBD::MySQL module in perl or the MySQL client rather than FreeRADIUS, despite our testing seeming to show it was OK. But I do not think that final ASSERT FAILED error should be being generated as a result of the former issue. I am trying to understand what is going on. Is FreeRADIUS attempting to kill the deadlocked threads and being unable to do so?
It's a corner case that wasn't being handled properly. Alan DeKok.