Hi, a question about the logrotate script: I understand that, upon SIGHUP, freeradius will reopen the main log file (radius.log). I also understand this does not extend to files written by linelog/detail modules; these need to be handled separately (with `radmin -e "hup xxx"'). However the logrotate script does not use such signalling, it rather opts for the copytruncate option. I wonder why that is the case. Is it the complexity of sending a signal to all modules (and all potential instances thereof)? Is it that, apart from re-opening the log file, SIGHUP will also cause the server to reload the (potentially broken) configuration? The copytruncate option avoids all that, but it is obviously slower/less efficient for rotating large log files. Or maybe is there a different reason behind this? Cheers, Z.
On Oct 17, 2017, at 11:21 AM, Zenon Mousmoulas <zmousm@noc.grnet.gr> wrote:
I understand that, upon SIGHUP, freeradius will reopen the main log file (radius.log). I also understand this does not extend to files written by linelog/detail modules; these need to be handled separately (with `radmin -e "hup xxx"'). However the logrotate script does not use such signalling, it rather opts for the copytruncate option. I wonder why that is the case.
It's largely historical.
Is it the complexity of sending a signal to all modules (and all potential instances thereof)?
The log rotate script also has to *know* about those modules. For all possible user configurations. That's not trivial. It's probably better to just fix FreeRADIUS to HUP linelog, etc. when the main server is HUPd.
Is it that, apart from re-opening the log file, SIGHUP will also cause the server to reload the (potentially broken) configuration?
That's possible, too. But a good administrator won't break a production system. Alan DeKok.
participants (2)
-
Alan DeKok -
Zenon Mousmoulas