Commit report for v3.1.x branch
New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Revert "logrotate: send a HUP after rotation" This is wrong, copyrotate is the correct command to use Arran Cudbard-Bell@2015-09-17T18:48:37Z Files modified: * scripts/logrotate/freeradius Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/e82215bd77c43a33c57e5... ====== logrotate: send a HUP after rotation Jorge Pereira (via Alan T. DeKok)@2015-09-17T17:04:18Z Files modified: * scripts/logrotate/freeradius Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/9ef068ab31f42d558b93d... ====== debian: Fixing logrotate script Jorge Pereira (via Alan T. DeKok)@2015-09-17T17:03:46Z Files modified: * debian/patches/logrotate-path.diff * debian/patches/series Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/680214839e3b9394ce3dd... ====== More RFCs Alan T. DeKok@2015-09-17T16:40:07Z Files modified: * doc/rfc/rfc7055.txt * doc/rfc/rfc7268.txt * doc/rfc/rfc7542.txt * doc/rfc/rfc7599.txt Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/7b8beaebfb6fc753cffdf... ====== if try to load a wrong client from SQL, don't start Jorge Pereira (via Alan T. DeKok)@2015-09-17T15:09:18Z Files modified: * src/modules/rlm_sql/rlm_sql.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/0f44899ef2e3c3002a145... ====== -- This commit summary was generated @2015-09-18T00:00:02Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed).
On Fri, Sep 18, 2015 at 12:00:02AM +0200, The git bot wrote:
====== Revert "logrotate: send a HUP after rotation"
This is wrong, copyrotate is the correct command to use ... https://github.com/FreeRADIUS/freeradius-server/commit/e82215bd77c43a33c57e5...
That method can lose log data, and really a hack for programs that can't close and reopen their own log files. The right way is to move the logfile, then signal the daemon to reopen its logfile, which is what the original version did. But the question really is how to signal. "killall -HUP radiusd" is verging on wrong (a variant of kill -HUP `cat $PIDFILE` would be more correct). I suspect /etc/init.d/freeradius reload is trying to do the latter, but is a) deprecated (it should be something like service freeradius reload) and b) possibly won't play well with systemd, however much any of us may hate it. The example in logrotate.conf(5) is postrotate kill -HUP `cat /var/run/inn.pid` endscript which would be best IMO - it doesn't play with init scripts or touch anything systemd related, is not as drastic as killall, and has no race. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 17 Sep 2015, at 23:29, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote:
On Fri, Sep 18, 2015 at 12:00:02AM +0200, The git bot wrote:
====== Revert "logrotate: send a HUP after rotation"
This is wrong, copyrotate is the correct command to use ... https://github.com/FreeRADIUS/freeradius-server/commit/e82215bd77c43a33c57e5...
That method can lose log data, and really a hack for programs that can't close and reopen their own log files.
Or something that will work universally with no massively negative side effects.
The right way is to move the logfile, then signal the daemon to reopen its logfile, which is what the original version did.
Yes, but not signal it with -HUP.
But the question really is how to signal. "killall -HUP radiusd" is verging on wrong (a variant of kill -HUP `cat $PIDFILE` would be more correct). I suspect /etc/init.d/freeradius reload is trying to do the latter, but is a) deprecated (it should be something like service freeradius reload) and b) possibly won't play well with systemd, however much any of us may hate it.
You use the control socket.
The example in logrotate.conf(5) is
postrotate kill -HUP `cat /var/run/inn.pid` endscript
which would be best IMO
Except it causes various modules to reload their configs, which is a completely unrelated operation. If multiple other daemons didn't do it this way, you'd consider it a bug: 'Signalled daemon to re-open logging handles, reloaded its configuration files as well'.
- it doesn't play with init scripts or touch anything systemd related, is not as drastic as killall, and has no race.
If you don't want to lose data, stop fucking around and use syslog, or use the control socket. Using HUP for reloading the config, and reopening log handles is idiotic in the extreme. I have no idea why multiple daemons use this method, other than perhaps laziness, and the lack of another 'standardised' signal. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Thu, Sep 17, 2015 at 11:45:29PM +0100, Arran Cudbard-Bell wrote:
The right way is to move the logfile, then signal the daemon to reopen its logfile, which is what the original version did.
Yes, but not signal it with -HUP.
Fair enough.
But the question really is how to signal. "killall -HUP radiusd"
You use the control socket.
That would work.
Using HUP for reloading the config, and reopening log handles is idiotic in the extreme. I have no idea why multiple daemons use this method, other than perhaps laziness, and the lack of another 'standardised' signal.
You're right. It should use -USR1 to reload the config, and -HUP for reopening the log files ;-P Is there a control socket command to do it - can't see one in 3.0.x? If so then radmin directly in the logrotate could work (if permissions are OK). But would need control-socket enabling by default, which it isn't at present. Incidentally, "help hup" in radmin segfaults the server. Pull request incoming. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Sep 17, 2015, at 7:44 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
You're right. It should use -USR1 to reload the config, and -HUP for reopening the log files ;-P
Nginx does: -s signal Send a signal to the master process. The signal can be one of: stop, quit, reopen, reload. The following table shows the corresponding system signals. • stop SIGTERM • quit SIGQUIT • reopen SIGUSR1 • reload SIGHUP That makes sense. And it's a bit more portable than "killall" or "kill".
Incidentally, "help hup" in radmin segfaults the server. Pull request incoming.
Weird. I'll take a look at the patch. Alan DeKok.
On 18 Sep 2015, at 01:15, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 17, 2015, at 7:44 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
You're right. It should use -USR1 to reload the config, and -HUP for reopening the log files ;-P
Nginx does:
-s signal Send a signal to the master process. The signal can be one of: stop, quit, reopen, reload. The following table shows the corresponding system signals.
• stop SIGTERM • quit SIGQUIT • reopen SIGUSR1 • reload SIGHUP
That makes sense. And it's a bit more portable than "killall" or "kill".
I'm fine with sacrificing the talloc memory dump stuff associated with SIGUSR1, especially since there's a command now. Also we need to remove the signal handler on SIGUSR2 as it interferes with valgrind. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Sep 18, 2015, at 4:55 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
I'm fine with sacrificing the talloc memory dump stuff associated with SIGUSR1, especially since there's a command now.
Also we need to remove the signal handler on SIGUSR2 as it interferes with valgrind.
Done. Alan DeKok.
participants (4)
-
Alan DeKok -
announce＠freeradius.org -
Arran Cudbard-Bell -
Matthew Newton