HUP handling: a thought
Frank Cusack
fcusack at fcusack.com
Fri May 4 23:53:45 CEST 2007
On May 4, 2007 1:40:16 PM -0400 Joe Maimon <jmaimon at ttec.com> wrote:
> Frank Cusack wrote:
>
>> On May 4, 2007 4:28:06 AM +0200 Alan DeKok <aland at deployingradius.com>
>
>>> 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.
-frank
More information about the Freeradius-Devel
mailing list