HUP handling: a thought

Frank Cusack fcusack at
Fri May 4 23:53:45 CEST 2007

On May 4, 2007 1:40:16 PM -0400 Joe Maimon <jmaimon at> wrote:
> Frank Cusack wrote:
>> On May 4, 2007 4:28:06 AM +0200 Alan DeKok <aland at>
>>>  Suggestions?
>> Add a config_t * to a REQUEST.  This would be exactly how you would do it
>> with some other library that is handling configuration.  (Except with
>> some other library the config_t * probably has both data and methods.)
>> The config_t itself would have a refcount (this can be updated via atomic
>> ops which don't require a mutex).  Then on HUP (or some type of reconfig
>> message), a new thread runs which reads the new config and globally
>> marks it current.  New REQUESTs get assigned the new config.  The config
>> thread waits for the refcount on the old config to go to 0, then reclaims
>> the memory and then exits.
>> Also, re-instantiate all modules.  The new instance will pick up the new
>> config.  When all previously running threads finally complete, destroy
>> the previous module instances.
> I assume the problem then comes in the handling of further packets for
> preexisting state, such as proxy replies and eap?

Oh, right.  Handling that would be slightly complex.  FR itself (as opposed
to modules) would have to understand State.  So if a packet came in with
State, it could decode the first byte or 2 and decide whether to hand it
to an old or new instance of a module.  The refcount idea would also be
invalid in this case, although maybe it's still useful in general (not
sure).  But for multi-packet transactions, the refcount could go to 0
yet there would still be pending transactions for an old module instance.

I guess a first version could simply ignore that problem.

> I suppose in that case, abandoning those wouldnt be so terrible,
> especialy as compared to a full restart which what most
> admins/distributions in the real world who havent implemented EVERYTHING
> via sql will be/already are doing.

Well the problem here is orthogonal to SQL AFAICT.


More information about the Freeradius-Devel mailing list