(RADIATOR) Memory Leak with PAM
hugh at open.com.au
Mon Jul 29 19:32:30 CDT 2002
Hello Mike -
I have copied this mail to Mike for his comments.
On Tuesday, July 30, 2002, at 05:40 AM, Forbes Mike wrote:
> What is the standard memory usage for radiator? We have 900 or so
> authenticating to this, is radiator keeping a state table of the
> and if so how much space would that take up per user. I am seeing
> memory continuing to ramp up from almost nothing to 30megs oon up to
> I am still trying to track down a memory leak with radiator
> via PAM (Kereberos). I have tested on a SUN which has a different PAM
> infrastructure than RedHat and get the same results as my RedHat
> test.(they could both have the leak I guess).
> As far as in depth testing of this, is this something I can take up
> tech support, or is there some direction you can point me on doing
> testing (not sure where to go to find a memory leak).
> Mike Forbes
> On Sat, 27 Jul 2002, Mike
> McCauley wrote:
>> Hello Dan,
>> I wasnt able to reproduce this problem here with Radiator 3.1, your
>> file and testing with
>> ./radpwtst -service_type Authenticate-Only -nas_port_type Virtual
>> -user mikem-fred -iterations 100000
>> On my linux box, size of raadiusd stabilised quickly at 5616 Kb.
>> What version of Radiator are you using, and what flags are you passing
>> to your
>> On Wed, 24 Jul 2002 08:54, Dan Melomedman wrote:
>>> Hugh Irvine writes:
>>>> Hello Dan -
>>>> Mike is travelling this week, but he will look at this when he
>>>> In the meantime, can you please tell me how you are testing? And
>>>> you also send me the details of how you are testing and the outputs
>>>> "ps", "top" or whatever you are using to measure the memory usage?
>>>> please include anything else that might be useful in tracing the
>>>> thanks and regards
>>> I am running radpwtst on the same machine recursively with a simple
>>> script, which does a correct query. Radiator authenticates using
>>> TEST. Until I stop it.
>>> This is before the script is run:
>>> ps auxw | egrep 'CPU|radiusd'
>>> USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
>>> radiusd 2202 0.1 0.6 8156 7760 p0 S+ 6:34PM 0:01.08
>>> /usr/local/bin/perl /usr/local/bin/radiusd -config_file ./test.cfg
>>> And after the script is finished (a few hundred querys):
>>> radiusd 2202 0.7 0.7 10196 9756 p0 S+ 6:34PM 0:07.74
>>> /usr/local/bin/perl /usr/local/bin/radiusd -config_file ./test.cf
>>> Note the difference in size and resident set size values. If the
>>> server and
>>> client are left to run longer, it will be so large that it will need
>>> to be
>>> restarted. I can do this automatically with daemontools, but it is
>>> not a
>>> This is not due a to a module load, since even on the first query, the
>>> process does not jump megabytes in size.
>> Mike McCauley mikem at open.com.au
>> Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
>> 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
>> Phone +61 3 9598-0985 Fax +61 3 9598-0955
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>> Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc
>> on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X etc etc
>> Archive at http://www.open.com.au/archives/radiator/
>> Announcements on radiator-announce at open.com.au
>> To unsubscribe, email 'majordomo at open.com.au' with
>> 'unsubscribe radiator' in the body of the message.
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator