(RADIATOR) Memory Leak with PAM

[Forbes Mike]

What is the standard memory usage for radiator?  We have 900 or so modems
authenticating to this, is radiator keeping a state table of the sessions
 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
250megs.

I am still trying to track down a memory leak with radiator authenticating
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 with
tech support, or is there some direction you can point me on doing
testing (not sure where to go to find a memory leak).

Thanks,

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 config
> file and testing with
>
> ./radpwtst -service_type Authenticate-Only -nas_port_type Virtual -notrace
> -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
> radpwtst?
>
>
> Cheers.
>
>
> 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 returns.
> > >
> > > In the meantime, can you please tell me how you are testing? And could
> > > you also send me the details of how you are testing and the outputs of
> > > "ps", "top" or whatever you are using to measure the memory usage? Also
> > > please include anything else that might be useful in tracing the problem.
> > >
> > > thanks and regards
> > >
> > > Hugh
> >
> > I am running radpwtst on the same machine recursively with a simple bash
> > script, which does a correct query. Radiator authenticates using AuthBy
> > 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
> > fix.
> >
> > This is not due a to a module load, since even on the first query, the
> > process does not jump megabytes in size.
> >
> > Thanks.
>
> --
> 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.