server cycles and memory utilization blamed on large radutmp radwtmp

[Alan DeKok]

Joe Maimon <jmaimon at ttec.com> wrote:
> Apparently something about those files being a couple hundered megabytes 
>   triggered the server to eat memory and cpu and generate<TIMEOUT> 
> errors, no available thread, and core dumps.

  Weird.  Very, very, weird.  All I can think of is that it took more
than 30s to root through radutmp.  That would cause problems.  One
solution would be to just stop using radutmp, and use a real database
when the size of the file gets large.

  For radwtmp, records are just appended, so there shouldn't be a
problem.

> +++ freeradius-2.0.0/src/modules/rlm_exec/rlm_exec.c	2006-01-24 18:35:58.000000000 -0500
> @@ -281,6 +281,13 @@
>  	VALUE_PAIR *answer;
>  	rlm_exec_t *inst = (rlm_exec_t *) instance;
>  
> +	if (!inst || !request) {
> +		radlof(L_ERR, "%s: %s() line: %d , a very bad thing happened",

  That should really be caught in the server core, before the module
is executed.  src/main/modcall.c tries to do this, I think.

> +++ freeradius-2.0.0~pre0~cvs20051222-0-JM/src/main/request_process.c	2006-01-24 17:41:13.000000000 -0500
> @@ -559,6 +559,7 @@
>  	 *	suppress packets which aren't supposed to be sent over
>  	 *	the wire, or to be delayed.
>  	 */
> +	if (request && request->listener && request->listener->send)

  Hmm... that may be better done by just bailing if the request is
deleted.

  The server doesn't handle deleting "live" requests that well.  It's
a problem.

> +++ freeradius-2.0.0/src/main/acct.c	2006-01-24 22:35:24.000000000 -0500
> @@ -152,7 +152,8 @@
>  		 */
>  		case RLM_MODULE_OK:
>  		case RLM_MODULE_UPDATED:
> -			request->reply->code = PW_ACCOUNTING_RESPONSE;
> +			if (request->reply)

  That should only be necessary if the request is free'd.  In that
case, the *only* thing to do is to bail out of handling the request.

  This is really what exceptions are for.

  Alan DeKok.