Segmentation fault on sigHUP

[Kostas Kalevras]

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
>>   freeradius
>> - 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
>