Re: Re: No cleanup for abandoned EAP requests in radiusd

[Kunal Solanki]

Thanks for replying Alan,
I have found the issue in my case, I was using external LDAP with 
radius and if LDAP is down then for the same EAP requests multiple 
authentication sessions were getting created. And as the cleanup of eap 
requests is plugged in processing of a reply message, this makes the 
cleanup happen only when a successful EAP request goes through.

I am thinking to put a cleanup in session creation path also which 
cleans very old sessions( double of usual timer limit 20 seconds. So I 
guess this will not impact any ongoing EAP request(not making to go to 
"no state variable" state for EAP request, an early delete of an 
handler).

Thanks,
Kunal Solanki 

On Wed, 23 Jun 2010 16:12:33 +0530  wrote
>Kunal Solanki wrote:

> I have been using freeradius version 2.1.4 and when I upgraded to 
2.1.7

> I am facing issues of high memory usage by radiusd. In 2.1.4 also the

> memory usage was quite high under high load but it used to come down

> after some time when abandoned requests are cleaned up. The cleanup

> trigger is not timer based in freeradius and is part of ongoing

> requests. In 2.1.7 version somehow this cleanup doesn't happen

> effectively and looks like for the same EAP requests a lot of 
dangling

> handlers are created which are not getting cleaned.



 You can instrument the code to see when they're getting cleaned up.

Or, edit it to clean up *more* of them at a time.



> I tried to cleanup

> old handlers in src/modules/rlm_eap/mem.c but that causes other

> side-affects of requests being present and no matching session state

> variable found for that.



 Uh... all you need to do is to change the "for" loop in

eaplist_expire, to loop over more entries.



> I believe in src/main/event.c we should have some sought of cleanup 
for

> the old requests itself.



 No. The server event loop doesn't deal with modules.



 Alan DeKok.

-

List info/subscribe/unsubscribe? See 
http://www.freeradius.org/list/devel.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20100623/1d7da8e8/attachment.html>