Project

General

Profile

Bug #2222

charon-systemd doesn't reopen the log file when SIGHUP is raised

Added by Noel Kuntze almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Category:
charon-systemd
Target version:
Start date:
15.01.2017
Due date:
Estimated time:
Affected version:
5.5.1
Resolution:
Fixed

Description

I have a logrotate setup with strongswan-swanctl. The daemon logs to /var/log/charon.log
logrotate rotates the logs to charon.log.[1-5], gzips and so on.

Now even if charon-systemd is raised SIGHUP, it continues logging to charon.log.1.
It never writes to charon.log, unless it is restarted. According to the [[|documentation]]
charon(-systemd) should reopen the log file when SIGHUP is raised.

I'm using 5.5.1

Associated revisions

Revision 68d97ac5
Added by Tobias Brunner almost 4 years ago

Merge branch 'charon-systemd-reload-loggers'

Allows reloading strongswan.conf, the loggers, and the plugins in
charon-systemd by sending a SIGHUP (as already supported by charon).

Loggers are now also reloaded by VICI's `reload-settings` command (works
with both daemons).

Fixes #2222.

History

#1 Updated by Tobias Brunner almost 4 years ago

  • Tracker changed from Issue to Bug
  • Status changed from New to Feedback
  • Target version set to 5.5.2

Now even if charon-systemd is raised SIGHUP, it continues logging to charon.log.1.
It never writes to charon.log, unless it is restarted. According to the [[|documentation]]
charon(-systemd) should reopen the log file when SIGHUP is raised.

charon-systemd actually does not handle SIGHUP. I pushed a commit that changes this to the 2222-charon-systemd-sighup branch. Let me know if that works for you.

Another option might be to reload the loggers after VICI's reload-settings command successfully reloaded the config (which it currently doesn't, probably because the plugin doesn't know the actual values of the two arguments if used with charon: source:src/libcharon/plugins/vici/vici_control.c#L624).

#2 Updated by Noel Kuntze almost 4 years ago

I think handling SIGHUP is the best solution, simply because people could edit settings when logrotate fires off and then the settings would be in an unknown state to the user (and he/she didn't know they were changed or why they daemon behaves differently).
I'll test and report.

EDIT: I think I misunderstood your comment. I thought SIGHUP only reopened the file and/or read the logger configuration. Well, if SIGUP also reads and updates strongswan.conf settings, I guess there's no advantage doing it either way. Having something to explicitely reopen the log files would be usefulm though.

#3 Updated by Noel Kuntze almost 4 years ago

That patch works fine.

#4 Updated by Tobias Brunner almost 4 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

Merged to master.

Also available in: Atom PDF