[freeradius 3.0.14] Issue on close and reopen file at reload

[Geaaru]

On Thu, 2017-08-24 at 16:56 +0800, Arran Cudbard-Bell wrote:
> > On 24 Aug 2017, at 15:57, Geaaru <geaaru at 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