Description of problem: After logrotate rotates /var/log/radius/radius.log, radius.log stays at 0 size, and output of daemon is still logged into radius.log.1 (the old rotated logfile) The problem can be fixed by integrating a kill -HUP into logrotate script to reload the deamon. Here is my working version: /var/log/radius/radacct/*/detail /var/log/radius/*.log /var/log/radius/radutmp { monthly rotate 10 nocreate create 640 radius adm missingok compress postrotate kill -HUP `cat /var/run/radiusd/radiusd.pid` endscript } According to RedHat, where the Bug was fixed a while ago, the problem is present since freeradius 2.1.9: https://bugzilla.redhat.com/show_bug.cgi?id=705723 as well as in Debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602815 Therefore MGA4 may be affected as well? Reproducible: Steps to Reproduce:
Does it work if you replace the logrotate config with Fedora's? http://pkgs.fedoraproject.org/cgit/freeradius.git/plain/freeradius-logrotate
CC: (none) => luigiwalser
Maybe, I would have to test (but my time is very limited at the moment) and I don't want to touch my working system right now. But I think just adding the last three lines of the example above to the original Mageia script would be the better alternative because: 1) The Fedora version uses /sbin/service to reload the daemon which is (according to the manpage) a service to "run a System V init script" and Mageia uses systemd by default 2) the files checkrad.log and sqltrace.sql which are rotated in Fedoras version are not created by default when using radiusd (not a real problem but more complex which is unnecessary) 3) not in line which RedHat and Debian
1) The service command redirects to systemctl under systemd. 2) Even if they're not created by default, if they could be created, they should be rotated, and the config says missingok, so it's OK if they're missing. 3) No, RedHat is built from Fedora and in fact is using the same file: https://git.centos.org/blob/rpms!freeradius.git/a827c021a04309b7ff9ad337365205b17b128063/SOURCES!freeradius-logrotate For maintenance purposes, it would be easier for us to copy Fedora's config as long as it works. Please test it when you get a chance and I'll commit it.
So I finally got the chance / time to test the referenced file in my working system. I found no problem so far as you pointed out in 1) and 2). As it is easier for you to copy Fedora's config you should do so! Furthermore it fixes the reported bug that the output of radiusd is logged into the already rotated file. Thanks for your help!
Thanks for reporting back. I had already checked this into SVN, but now I've pushed a build for Mageia 5. Please test it and verify that it's OK (it should be basically the same as what you're using now, so I wouldn't expect any issues) and what architecture you tested. Advisory: ---------------------------------------- Due to an error in freeradius's logrotate configuration, after log rotation, it would continue to write to the old log file instead of the new one. This error has been corrected. ---------------------------------------- Updated packages in core/updates_testing: ---------------------------------------- freeradius-2.2.8-1.1.mga5 freeradius-krb5-2.2.8-1.1.mga5 freeradius-ldap-2.2.8-1.1.mga5 freeradius-postgresql-2.2.8-1.1.mga5 freeradius-mysql-2.2.8-1.1.mga5 freeradius-unixODBC-2.2.8-1.1.mga5 freeradius-sqlite-2.2.8-1.1.mga5 freeradius-yubikey-2.2.8-1.1.mga5 libfreeradius1-2.2.8-1.1.mga5 libfreeradius-devel-2.2.8-1.1.mga5 freeradius-web-2.2.8-1.1.mga5 from freeradius-2.2.8-1.1.mga5.src.rpm
Assignee: bugsquad => qa-bugs
Installation works without any problems. /etc/logrotate.d/radiusd was created as /etc/logrotate.d/radiusd.rpmnew Diff between this two files showed only my local changes to rotate 10 instead of 4 times.
Whiteboard: (none) => MGA5-32-OK
This can be validated, as the change is not arch-specific.
Whiteboard: MGA5-32-OK => MGA5-32-OK advisoryKeywords: (none) => validated_updateCC: (none) => davidwhodgins, sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2015-0163.html
Status: NEW => RESOLVEDResolution: (none) => FIXED