Segmentation fault on sigHUP
kkalev at noc.ntua.gr
Fri Apr 13 11:49:11 CEST 2007
O/H Alan DeKok έγραψε:
> Milan Holub wrote:
>> - we are keeping NAS entries in DB.
> Then the server should re-load them via reading the DB.
>> - these entries are edited by operation guys via web interface
>> - when a new NAS entry is added then we need to reload/restart
>> - we reload freeradius using SNMP write query(can be done via web
>> interface as well; without need of ssh to radius server)
> If the server automatically discovers NAS changes from the DB, then
> the server doesn't need to be reloaded.
> i.e. You're changing *one* thing: a NAS. You're then telling the
> server to reload *everything*. That's where the expense and complexity
> comes in.
The problem is: You add one NAS. But you need to update the clients
list. To do that you have to lock the clients list for write and make
sure no one reads it. That means you have to stop accepting requests and
wait for already present ones to finish. Afterwards you just have to
start accepting requests again. The same more or less applies to changes
on module configuration (CRLs for TLS, users for the files module). You
have to reload the module and in the meantime make sure no one uses it
(and the best way to do that is by stop accepting requests). This all
sounds like the work done on a HUP so i don't see any major differences.
>> In general when restarting the server you might loose some radius
>> packets(especially on high loaded server), don't you?
> It's possible.
>> ==> what do you imagine under these "features"? Basically I thought HUP
>> is good for reloading config files when one does not want to bring the
>> server down but wants to bring into effect some minor config change.
> I am trying to say that there are OTHER ways to perform some minor
> config change than HUP. HUP should be the *last* resort.
>> ==> is there any other use of HUP?
> No. HUP is *only* to notify the server of configuration changes.
> 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/users.html
More information about the Freeradius-Users