HUP handling: a thought
jmaimon at ttec.com
Fri May 4 19:40:16 CEST 2007
Frank Cusack wrote:
> On May 4, 2007 4:28:06 AM +0200 Alan DeKok <aland at deployingradius.com>
> 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?
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.
More information about the Freeradius-Devel