(RADIATOR) Memory Leak with PAM
Forbes Mike
Mike.Forbes at Colorado.EDU
Tue Jul 30 01:31:46 CDT 2002
We have experienced it running 2.19 on Solaris and running 3.1 on RedHat.
Both of these are using the kerberos 5 pam from redhat.
The config is below.
Mike
LogDir /var/log/radius
DbDir /usr/local/radiator
# Use a low trace level in production systems. Increase
# it to 4 or 5 for debugging, or use the -trace flag to radiusd
#Trace 4
#<SNMPAgent>
# ROCommunity
#</SNMPAgent>
# You will probably want to add other Clients to suit your site,
# one for each NAS you want to work with
<Client DEFAULT>
DupInterval 0
DefaultRealm MODEMS
</Client>
<AuthLog FILE>
Identifier Modem_Login_Failures
Filename %L/Modem_Login_Failures
LogFailure 1
FailureFormat %l:NAS %N
User:%U:%T:%{NAS-Port-Type}:%{Calling-Station-Id}:%1:Fail
</Authlog>
<AuthLog FILE>
Identifier Backbone_Login_Failures
Filename %L/Backbone_Login_Failures
LogFailure 1
FailureFormat %l:NAS %N User:%U:%T:%{NAS-Port-Type}:From
%{Calling-Station-Id}:%1
:Fail
</Authlog>
<AuthLog FILE>
Identifier Datacomm_Login_Failures
Filename %L/Datacomm_Login_Failures
LogFailure 1
FailureFormat %l:NAS %N
User:%U:%T:%{NAS-Port-Type}:%{Calling-Station-Id}:%1:Fail
</Authlog>
<AuthLog FILE>
Identifier VPN_Login_Failures
Filename %L/VPN_Login_Failures
LogFailure 1
FailureFormat %l:NAS %N User:%U:%T:%{NAS-Port-Type}:From
%{Calling-Station-Id}:%1
:Fail
</Authlog>
<Handler Realm=MODEMS,NAS-Port-Type=Async,NAS-IP-Address=128.138.x.x>
RewriteUsername s/^([^@]+).*/$1/
<AuthBy GROUP>
AuthByPolicy ContinueUntilReject
<AuthBy PAM>
Service radiusd
</AuthBy>
<AuthBy FILE>
Filename %D/backbone_users
</AuthBy>
</AuthBy>
AuthLog Modem_Login_Failures
</Handler>
<Handler Realm=MODEMS,NAS-Port-Type=Virtual>
RewriteUsername s/^([^@]+).*/$1/
<AuthBy GROUP>
AuthByPolicy ContinueUntilReject
<AuthBy PAM>
Service radiusd
</AuthBy>
<AuthBy FILE>
Filename %D/backbone_users
</AuthBy>
</AuthBy>
AuthLog Backbone_Login_Failures
# Log accounting to a detail file
AcctLogFileName %L/modems_backbone_users
</Handler>
<Handler Realm=MODEMS>
RewriteUsername s/^([^@]+).*/$1/
<AuthBy GROUP>
AuthByPolicy ContinueUntilReject
<AuthBy PAM>
Service radiusd
</AuthBy>
</AuthBy>
AuthLog Modem_Login_Failures
AcctLogFileName %L/Modems
</Handler>
<Handler Realm=Off_Campus_VPN>
RewriteUsername s/^([^@]+).*/$1/
<AuthBy GROUP>
AuthByPolicy ContinueUntilReject
<AuthBy PAM>
Service radiusd
</AuthBy>
</AuthBy>
AuthLog VPN_Login_Failures
AcctLogFileName %L/Off_Campus_VPN
</Handler>
<Handler Realm=Backbone_Devices>
RewriteUsername s/^([^@]+).*/$1/
<AuthBy GROUP>
AuthByPolicy ContinueUntilReject
<AuthBy PAM>
Service radiusd
</AuthBy>
<AuthBy FILE>
Filename %D/backbone_users
</AuthBy>
</AuthBy>
AuthLog Backbone_Login_Failures
# Log accounting to a detail file
AcctLogFileName %L/backbone_devices
</Handler>
<Handler Realm=Datacomm_Devices>
RewriteUsername s/^([^@]+).*/$1/
<AuthBy GROUP>
AuthByPolicy ContinueUntilReject
<AuthBy PAM>
Service radiusd
</AuthBy>
<AuthBy FILE>
Filename %D/backbone_users
</AuthBy>
</AuthBy>
AuthLog Datacomm_Login_Failures
# Log accounting to a detail file
AcctLogFileName %L/datacomm_devices
</Handler>
<Client 128.138.x.x>
# tcom5300
DefaultRealm MODEMS
</Client>
More identical clients for remaining term servers.
<Client 128.138.x.x>
# rgnt-6500
DefaultRealm Backbone_Devices
</Client>
More indentical clients.
On Tue, 30 Jul 2002, Mike McCauley wrote:
> Hello Mike,
>
>
> On Tue, 30 Jul 2002 10:32, Hugh Irvine wrote:
> > Hello Mike -
> >
> > I have copied this mail to Mike for his comments.
>
> I would normally expect to see a Radiator process to stabilise at 5 to 10 MB
> (depending on the exact config in use).
>
> Dan has independently indicated that his problem seems to be FreeBSD specific.
> What OS and platform are you on?
>
>
> >
> > regards
> >
> > Hugh
> >
> > 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
> > > 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.
>
> --
> 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.
More information about the radiator
mailing list