[freeradius 3.0.14] Issue on close and reopen file at reload
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. 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. Is there an open issue about this? I remember that this problem was happens already in the past. Thank you in advance for any suggestions. G.
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?
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. 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? -Arran
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
On Aug 24, 2017, at 4:56 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
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?
It's already there. $ radmin -e "hup linelog" Alan DeKok.
Yeah thanks. Now from log I see correctly info about Reloaded module but so, the right question is why is not called hup automatically from main SIGHUP ? FWIS there is a check about type of the module and linelog correctly has flag RLM_TYPE_HUP_SAFE so I don't understand why I don't find log about reloading of the module? Could be related with a problem to handle multiple module linelog (needed in my case to log same packets with different line log)? radmin> show module list auth_log (detail) reply_log (detail) pre_proxy_log (detail) post_proxy_log (detail) reject (always) fail (always) ok (always) handled (always) invalid (always) userlock (always) notfound (always) noop (always) updated (always) cache_auth (cache) cache_ip (cache) chap detail delayed.acct1 (detail) dynamic_clients expr log_accounting (linelog) log_auth2proxy (linelog) log_auth_resp (linelog) log_block_resp (linelog) log_acct_resp_from_proxy (linelog) pap radutmp IPASS (realm) suffix (realm) realmpercent (realm) ntdomain (realm) replicate sql (sql) sql_cache (sql) sqlippool sradutmp (radutmp) utf8 radmin> Obviously, in my case is needed radmin -e "hup log_accounting" , etc. Thanks again for this clarification. G. On Thu, 2017-08-24 at 06:57 -0400, Alan DeKok wrote:
On Aug 24, 2017, at 4:56 AM, Arran Cudbard-Bell <a.cudbardb@freeradiu s.org> wrote:
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?
It's already there.
$ radmin -e "hup linelog"
Alan DeKok.
On Aug 24, 2017, at 7:22 AM, Geaaru <geaaru@gmail.com> wrote:
Yeah thanks. Now from log I see correctly info about Reloaded module but so, the right question is why is not called hup automatically from main SIGHUP ?
The server reloads modules if their configuration has changed. If there's no configuration change, the module isn't reloaded. The linelog module is a bit different. It opens output files, which need to be closed and re-opened on HUP. The server core doesn't (yet) know this about the linelog module, so it doesn't reload linelog on HUP. It's probably easy to add another module flag: RLM_TYPE_RELOAD_ON_HUP, and have the server core reload the module on HUP, even if the configuration hasn't changed.
FWIS there is a check about type of the module and linelog correctly has flag RLM_TYPE_HUP_SAFE so I don't understand why I don't find log about reloading of the module?
That's for reloading the configuration.
Could be related with a problem to handle multiple module linelog (needed in my case to log same packets with different line log)?
What's that problem?
Obviously, in my case is needed radmin -e "hup log_accounting" , etc.
Yes. Alan DeKok.
Ok, now is more clear. Yes, probably it is needed add a RLM_TYPE_RELOAD_ON_HUP to reload a module also when there aren't changes on configuration. When I have a bit of time I will try to prepare a pull request about this. Thank you very very much at all for a so fast reply. G. On Thu, 2017-08-24 at 07:39 -0400, Alan DeKok wrote:
On Aug 24, 2017, at 7:22 AM, Geaaru <geaaru@gmail.com> wrote:
Yeah thanks. Now from log I see correctly info about Reloaded module but so, the right question is why is not called hup automatically from main SIGHUP ?
The server reloads modules if their configuration has changed. If there's no configuration change, the module isn't reloaded.
The linelog module is a bit different. It opens output files, which need to be closed and re-opened on HUP. The server core doesn't (yet) know this about the linelog module, so it doesn't reload linelog on HUP.
It's probably easy to add another module flag: RLM_TYPE_RELOAD_ON_HUP, and have the server core reload the module on HUP, even if the configuration hasn't changed.
FWIS there is a check about type of the module and linelog correctly has flag RLM_TYPE_HUP_SAFE so I don't understand why I don't find log about reloading of the module?
That's for reloading the configuration.
Could be related with a problem to handle multiple module linelog (needed in my case to log same packets with different line log)?
What's that problem?
Obviously, in my case is needed radmin -e "hup log_accounting" , etc.
Yes.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/d evel.html
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Geaaru