Can I just check, as I can't seen anything about it in the changelog and the wiki page for it appears to be the same as before - What is the rlm_perl behaviour with the new version of FreeRADIUS?
As I recall rlm_perl no longer handles its own threading. One of the issues for several people introduced with the previous version of FreeRADIUS was there only ever being a single perl thread, which was a bottleneck, where the desired functionality was 1 perl thread (or process, if compiled with multiplicity instead of threading) per radius thread. I'm also assuming multiplicity takes preference, as our system installed with 2.1.4 had perl installed with both, and our radius process starts up at 200M but doesn't grow in the way you'd expect if we had a memory leak in our perl. I can't think what's taking up all that memory if it's not multiple perl processes. The same code on a system with perl compiled without threading or multiplicity only takes 16M. Thanks for the update, the radwatch script in particular will be very useful for us :) -- Dan Meyers Network Specialist, Lancaster University E-Mail: d.mey...@lancaster.ac.uk - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html