On Thu, 2017-08-24 at 16:56 +0800, Arran Cudbard-Bell wrote:
On 24 Aug 2017, at 15:57, Geaaru <geaaru@gmail.com> wrote:
Hi guys,
I installed yesterday version 3.0.14 but I found a strange issue.
I configured my server to use linelog module to trace radius packets but I see only now that when is called reload (SIGHUP) for logrotate linelog continue to write on moved file and not correctly file. While on correct log I see classic message
Thu Aug 24 09:54:37 2017 : Info: Received HUP signal Thu Aug 24 09:54:37 2017 : Info: HUP - No files changed. Ignoring
linelog module continue to write to old file.
This means that when old file is compressed on next logrotate freeradius server go in SEGFAULT.
Well it obviously shouldn’t SEGV. Where does that happen exactly?
Probably because on next logrotate old file is then compressed (at least in my configuration) and for what I see on others software is not so good. Maybe because fseek done previous from server is relative to a memory area changed and/or not relative to real file position after compression.
Linelog module write a lot of message so could be a concurrency problem on handle SIGHUP but this issue is not present on previous installed version 3.0.8.
Yes I think older versions reopened the FD on every write. I don’t think there’s any internal mechanisms to distribute signals.
Mmm... but FWIS there aren't so big changes between 3.0.8 and 3.0.14 about this. Both use exfile_* function and reopen every time FD. Correct? So, I don't understand why on SIGHUP is always used old fd. Could be related with a missing management of ex_file mutex on linelog module ?
Maybe that’s a bit of a major change for v3.0.x. What’s the core team’s opinion an implementing an extra method for modules to deal with SIGHUP?
From outside team... yes could be a valid solution.
Thanks for your reply.
-Arran