December 2006 - Freeradius-Devel - lists.freeradius.org

Latest cvs debian build with udpfromto and smux
by Joe Maimon 14 Dec '06

14 Dec '06

During linking udpfromto and smux were unresolved I brute forced it by placing a #define WITH_xxx 1 at the top of the source file. Apparently those two arent defined to 1 in autconf.h Is this something specific to me?

3 2

Automatic report from sources (radiusd) between 13.12.2006 - 14.12.2006 GMT
by Automatic cvs log generator 14 Dec '06

14 Dec '06

CVS log entries from 13.12.2006 (Wed) 09:00:01 - 14.12.2006 (Thu) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: pnixon File: radiusd/doc/DIFFS; Revisions: 1.5 ===================================================== Log entries ===================================================== Description: Fix list address Modified files: File: radiusd/doc/DIFFS; Revision: 1.5; Date: 2006/12/13 13:33:34; Author: pnixon; Lines: (+1 -1) ===================================================== Summary of modified files ===================================================== File: radiusd/doc/DIFFS Revisions: 1.5 Authors: pnixon (+1 -1) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Automatic report from sources (radiusd) between 12.12.2006 - 13.12.2006 GMT
by Automatic cvs log generator 13 Dec '06

13 Dec '06

CVS log entries from 12.12.2006 (Tue) 09:00:01 - 13.12.2006 (Wed) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/threads.c; Revisions: 1.114 Author: pnixon File: radiusd/doc/examples/postgresql.sql; Revisions: 1.11, 1.1.2.7 File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/sql_postgresql.c; Revisions: 1.49, 1.48, 1.47 ===================================================== Log entries ===================================================== Description: Fix syntax typo Modified files: File: radiusd/doc/examples/postgresql.sql; Revision: 1.11; Date: 2006/12/12 12:08:48; Author: pnixon; Lines: (+2 -2) ------------------------------- Description: oops. invalid syntax.. Test things before you commit to cvs peter! Modified files: File: radiusd/doc/examples/postgresql.sql; Revision: 1.1.2.7; Date: 2006/12/12 12:10:30; Author: pnixon; Lines: (+2 -2) ------------------------------- Description: Fix stupid bug. rad_send() takes secret as second argument, listener->send takes REQUEST* Modified files: File: radiusd/src/main/threads.c; Revision: 1.114; Date: 2006/12/12 19:56:48; Author: aland; Lines: (+3 -3) ------------------------------- Description: Minor formatting cleanups. Modified files: File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/sql_postgresql.c; Revision: 1.49; Date: 2006/12/12 16:15:06; Author: pnixon; Lines: (+6 -8) ------------------------------- Description: Code is a bit clearer this way. Functionality should not change. Modified files: File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/sql_postgresql.c; Revision: 1.48; Date: 2006/12/12 16:03:38; Author: pnixon; Lines: (+4 -4) ------------------------------- Description: Fix a STUPID memory leak introduced by yours truely.. Modified files: File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/sql_postgresql.c; Revision: 1.47; Date: 2006/12/12 11:51:44; Author: pnixon; Lines: (+2 -5) ===================================================== Summary of modified files ===================================================== File: radiusd/doc/examples/postgresql.sql Revisions: 1.11, 1.1.2.7 Authors: pnixon (+2 -2), pnixon (+2 -2) ------------------------------- File: radiusd/src/main/threads.c Revisions: 1.114 Authors: aland (+3 -3) ------------------------------- File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/sql_postgresql.c Revisions: 1.49, 1.48, 1.47 Authors: pnixon (+6 -8), pnixon (+4 -4), pnixon (+2 -5) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Re: Memory Use
by Abdul Qadir 11 Dec '06

11 Dec '06

> With which sql backend? I am using Oracle 9. Message: 2 Date: Mon, 11 Dec 2006 11:49:37 +0200 From: Peter Nixon <listuser(a)peternixon.net> Subject: Re: memory use To: FreeRadius developers mailing list <freeradius-devel(a)lists.freeradius.org> Message-ID: <200612111149.43049.listuser(a)peternixon.net> Content-Type: text/plain; charset="iso-8859-15" On Mon 11 Dec 2006 06:28, Abdul Qadir wrote: > >Which modules are you using? There haven't been reports of memory > > leaks in the server for quite a while, so your configuration may be > > using parts of the server that no one else uses. > > I am using rlm_digest and rlm_sql With which sql backend? --------------------------------- Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.

1 0

Re: memory use
by Abdul Qadir 11 Dec '06

11 Dec '06

>Which modules are you using? There haven't been reports of memory > leaks in the server for quite a while, so your configuration may be > using parts of the server that no one else uses. I am using rlm_digest and rlm_sql Message: 3 Date: Thu, 07 Dec 2006 19:58:35 -0800 From: Alan DeKok <aland(a)deployingradius.com> Subject: Memory use To: FreeRadius developers mailing list <freeradius-devel(a)lists.freeradius.org> Message-ID: <4578E2EB.5020904(a)deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1 Abdul Qadir wrote: > This thing is very nice that server is doing caching. But i think its > still server's responsibilty to release all memory even the cache memroy > at time of exit. Ideally, yes. Patches are welcome. > Yes the memory keeps on growing, otherwise y I would be looking into > Valgrind logs and trying to find out whats wrong with the server. And > this leak becomes very clear when the number of requests become greater. Which modules are you using? There haven't been reports of memory leaks in the server for quite a while, so your configuration may be using parts of the server that no one else uses. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog --------------------------------- Any questions? Get answers on any topic at Yahoo! Answers. Try it now.

2 1

Automatic report from sources (radiusd) between 08.12.2006 - 09.12.2006 GMT
by Automatic cvs log generator 09 Dec '06

09 Dec '06

CVS log entries from 08.12.2006 (Fri) 09:00:01 - 09.12.2006 (Sat) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/include/radius.h; Revisions: 1.66.4.3 File: radiusd/share/dictionary.freeradius.internal; Revisions: 1.6.2.6 ===================================================== Combined list of identical log entries ===================================================== Description: Defined Cleartext-Password and Password-With-Header, taken from the CVS head Modified files: File: radiusd/share/dictionary.freeradius.internal; Revision: 1.6.2.6; Date: 2006/12/09 00:17:37; Author: aland; Lines: (+3 -1) File: radiusd/src/include/radius.h; Revision: 1.66.4.3; Date: 2006/12/09 00:17:36; Author: aland; Lines: (+3 -1) ===================================================== Log entries ===================================================== ===================================================== Summary of modified files ===================================================== File: radiusd/share/dictionary.freeradius.internal Revisions: 1.6.2.6 Authors: aland (+3 -1) ------------------------------- File: radiusd/src/include/radius.h Revisions: 1.66.4.3 Authors: aland (+3 -1) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Re: Re: accounting_reply_query (corrected)
by Alexander S. Holodny 08 Dec '06

08 Dec '06

> Why? Accounting-Response packets are empty. by RFC - may be; i've not read it. > Which NAS other than your patched PPPd supports this? If the answer > is "none", then the patch isn't useful to anyone other than you. don't know about NAS. but, i saw some radiusd configs, which uses servers ability to send "Accounting-Response" packets using EXEC module. that's why i thought, that "Accounting-Response" can be sent to NASes. and my patch makes it easy. one of them: ... exec kicker { wait = yes program = "/usr/bin/kicker %{User-Name} %{Acct-Status-Type}" input_pairs = request output_pairs = reply packet_type = Accounting-Request } accounting { sql kicker } ...

2 1

Re: Freeradius-Devel Digest, Vol 20, Issue 4
by Abdul Qadir 08 Dec '06

08 Dec '06

Hi, >The server caches requests and responses for a time, so if you kill > the server immediately after a response is sent, there may be many > requests and responses still in memory. This thing is very nice that server is doing caching. And I think there should be some limit on caching memory or its unlimited. I don't know exactly what it is. But i think its still server's responsibilty to release all memory even the cache memroy at time of exit. >i.e. memory *lost* while it is running is bad. Slow memory growth > over time is bad. The problems you're seeing are likely unimportant. The problem we are seeing is that the memory keeps on growing and growing, therefore we wrote some cron job which kills the server and restart it. But its not the right solution for a production system. >If you leave the server running, does it's total memory use grow over > time? If not, there's probably no memory leak. Yes the memory keeps on growing, otherwise why I would be looking into Valgrind logs and trying to find out whats wrong with the server. And this leak becomes very clear when the number of requests become greater. I thought it would some minor issue which can be fixed quickly, but it seems like some thing else, which need assistance from your side. Best Regards, Abdul Qadir Message: 6 Date: Thu, 07 Dec 2006 18:19:52 -0800 From: Alan DeKok Subject: Re: FreeRadius 1.1.3 Memory Leak To: FreeRadius developers mailing list Message-ID: <4578CBC8.1030907(a)deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1 Abdul Qadir wrote: > Actually the problem is why this keeps on grwoing. If i start the > process and exit it the statistics are different If i send some > authentication request, the memory which is not freed by the process at > exit keeps on growing. Is there any solution for this. Please see the > difference below. The server caches requests and responses for a time, so if you kill the server immediately after a response is sent, there may be many requests and responses still in memory. i.e. memory *lost* while it is running is bad. Slow memory growth over time is bad. The problems you're seeing are likely unimportant. If you leave the server running, does it's total memory use grow over time? If not, there's probably no memory leak. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog ------------------------------ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html End of Freeradius-Devel Digest, Vol 20, Issue 4 *********************************************** --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.

2 1

Re: Freeradius-Devel Digest, Vol 20, Issue 4
by Abdul Qadir 07 Dec '06

07 Dec '06

Hi, >The server caches requests and responses for a time, so if you kill > the server immediately after a response is sent, there may be many > requests and responses still in memory. This thing is very nice that server is doing caching. But i think its still server's responsibilty to release all memory even the cache memroy at time of exit. >If you leave the server running, does it's total memory use grow over > time? If not, there's probably no memory leak. Yes the memory keeps on growing, otherwise y I would be looking into Valgrind logs and trying to find out whats wrong with the server. And this leak becomes very clear when the number of requests become greater. Best Regards, Abdul Qadir ----------------------------- Message: 6 Date: Thu, 07 Dec 2006 18:19:52 -0800 From: Alan DeKok Subject: Re: FreeRadius 1.1.3 Memory Leak To: FreeRadius developers mailing list Message-ID: <4578CBC8.1030907(a)deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1 Abdul Qadir wrote: > Actually the problem is why this keeps on grwoing. If i start the > process and exit it the statistics are different If i send some > authentication request, the memory which is not freed by the process at > exit keeps on growing. Is there any solution for this. Please see the > difference below. The server caches requests and responses for a time, so if you kill the server immediately after a response is sent, there may be many requests and responses still in memory. i.e. memory *lost* while it is running is bad. Slow memory growth over time is bad. The problems you're seeing are likely unimportant. If you leave the server running, does it's total memory use grow over time? If not, there's probably no memory leak. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog ------------------------------ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html End of Freeradius-Devel Digest, Vol 20, Issue 4 *********************************************** --------------------------------- Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.

2 1

Re: FreeRadius 1.1.3 Memory Leak
by Abdul Qadir 07 Dec '06

07 Dec '06

Hi, I agree with you that this memory is not freed when the process exit. Actually the problem is why this keeps on grwoing. If i start the process and exit it the statistics are different If i send some authentication request, the memory which is not freed by the process at exit keeps on growing. Is there any solution for this. Please see the difference below. This Paragraph show when no request was sent ==811== LEAK SUMMARY: ==811== definitely lost: 108 bytes in 7 blocks. ==811== possibly lost: 340 bytes in 5 blocks. ==811== still reachable: 1,353,886 bytes in 25,961 blocks. ==811== suppressed: 0 bytes in 0 blocks. ==811== Reachable blocks (those to which a pointer was found) are not shown. ==811== To see them, rerun with: --show-reachable=yes This Paragraph show when few authentication requests were sent. ==842== LEAK SUMMARY: ==842== definitely lost: 108 bytes in 7 blocks. ==842== possibly lost: 476 bytes in 7 blocks. ==842== still reachable: 1,353,950 bytes in 25,963 blocks. ==842== suppressed: 0 bytes in 0 blocks. ==842== Reachable blocks (those to which a pointer was found) are not shown. ==842== To see them, rerun with: --show-reachable=yes Best Regards, Abdul Qadir Message: 2 Date: Thu, 07 Dec 2006 01:47:54 -0800 From: Alan DeKok Subject: Re: FreeRadius 1.1.3 Memory Leak To: FreeRadius developers mailing list Message-ID: <4577E34A.8070203(a)deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1 Abdul Qadir wrote: > Hi, > > I just configured radius 1.1.3 and found that there are some memory > leaks in it. > > Here is the output of Valgrind i.e. memory is not free'd when the process exits. This is not a "memory leak" that will affect anything. The only reason to fix these issues is to prevent valgrind from complaining about them. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog ------------------------------ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html End of Freeradius-Devel Digest, Vol 20, Issue 3 *********************************************** --------------------------------- Any questions? Get answers on any topic at Yahoo! Answers. Try it now.

2 1