memory leaks and other problems with rlm_ippool
mgriego at utdallas.edu
Wed Aug 24 17:12:12 CEST 2005
I've been seeing the same issue and have been trying to track it down
for over a year. I'm not running ippools, though, but I get a large
number of EAP conversations. Until I could track it down, I've got a
script in place to kill/restart the daemon when it reaches 400MB. I've
also been kinda watching for others seeing similar issues, and,
honestly, this is the first thing I've seen that comes close.
My setup is Fedora Core 1, fully patched, on a Dell PowerEdge 650
(2.4GHz P4, 512MB RAM). The daemon grows in memory usage unchecked over
time even in full -X debug mode.
I'd be very interested in comparing notes. I've been valgrinding the
heck out of the server and can't seem to figure out where the leak is,
even though I've found and fixed a couple of leaks in my own checking.
Those haven't fixed the memory growth problem. I'm convinced that
something somewhere has an off-by-one bug or something similar and is
horking the memory manager. I have yet to be able to track this down
Peter Nixon wrote:
>I am consistently finding that if you create more than one IP Pool bigger
>than a class B network that FreeRADIUS fails to start with an error saying
>that it cannot fork. It can however be run in debug mode with this config.
>I have tested this on a number of different servers with a number of
>different versions of FreeRADIUS and on SUSE Linux Enterprise 9, SUSE Pro
>9.2, SUSE Pro 9.3 and some random version of Turbo Linux that a customer
>Also, one customer who had only a single class B IP Pool with about 10,000
>clients connecting and disconnecting on a regular basis (Around 300 Auth
>requests and associated Accounting packets per minute between 8am and
>midnight) is seeing their FreeRADIUS grow over the course of a couple of
>days until the Linux OOM killer kills it. (Making their customers very
>unhappy until they restart their server) Their server is fully patched
>SLES9 running FreeRADIUS 1.0.4
>Does anyone have any ideas? Surely someone else must have seen these
>problems. I can't be the only person running multiple, large IP Pools...
More information about the Freeradius-Devel