Commit report for v3.1.x branch - logrotate

[Arran Cudbard-Bell]

> On 17 Sep 2015, at 23:29, Matthew Newton <mcn4 at 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/e82215bd77c43a33c57e5f17fb404ec32f05263f
> 
> 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 at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20150917/4fdf66a6/attachment.sig>