I remember vaguely that HUPing was at least once used to re-read updated CRLs and probably also re-reading the list/directory of trusted client-CA certificates for all the EAP-(T)TLS/PEAP stuff.
Yes.
that was me, so to the list of 'other things' other than re-read clients, realms and the users files I'd like to add re-read of CRLs (and certificates). The reason for me being so boring is that a proper implementation of EAP-(T)TLS requires the server to handle all the CA chain and CRL updates crap. CRLs unfortunately DO expire. Expired CRL == the properly implemented EAP-TLS structure falls apart and everybody gets a reject due to 'expired' certs. Therefore, if you release a CRL because you have a properly implemented CA and TLS infrastructure you must also reload it to the radiusd or everything breaks and you get a VERY poor uptime ~_~. If there's no chance to realod a CRL without an /etc/init.d/radiusd restart then I'll stick to restarting the process during offpeak hours. Not using a CRL at all is not an option when a major amount of users enter and/or leave your organization each year and you use TLS. As a side note, I know this sucks. Maybe I'm one othe few around the world fool enough to go all the way down to CRLs. As a foot note: I suppport Alan's idea. Let's forget about HUP. Experience shows HUP is clearly not suited for something with a system state and personally I don't accept a solution that makes an otherwise perfectly stable daemon to occasionally crater. If HUP is not going to work, let's do it another way. SQL sounds good to me. As long as it reloads a CRL too ^_-
HUP does something in 1.x. It will cause the server to re-read the configuration files. It *may* also cause the server to die unexpectedly.
Too bad my test server dies with excellent consistency when I HUP it :P