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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
