Feature #265
closedreopen log file to support log rotate
Description
It would be better if suricata can receive a USR signal and reopen log file, so log ratate can
be done easily.
Updated by Victor Julien almost 14 years ago
- Assignee set to Victor Julien
- Target version set to 1.1beta2
Will be a task to one of the OISF devs.
Updated by Victor Julien over 13 years ago
- Target version changed from 1.1beta2 to 1.1beta3
Updated by Victor Julien about 13 years ago
- Target version changed from 1.1beta3 to 1.2
Updated by Victor Julien almost 13 years ago
- Status changed from New to Closed
- Target version deleted (
1.2)
From: http://lists.openinfosecfoundation.org/pipermail/oisf-users/2011-November/001087.html
cp http.log http.log.1 && > http.log
I tested this and it works.
Updated by Jorgen Bohnsdalen over 12 years ago
Today Suricata (1.3.1) doesn't reopen the logfiles when doing a logrotate. Since HTTP-logs tend to be huge, it'd be nice if Suricata supported receiving a signal for re-opening log-files. The solution provided here is not a solution for this feature. Logrotating is something that most definitely should be supported without restarting Suricata (and possibly suffering a few minutes of downtime).
Updated by Victor Julien over 12 years ago
Did you try the solution at comment 4? It works fine for me w/o the need for restarting Suricata.
Updated by Jorgen Bohnsdalen over 12 years ago
Yes, I tried it. It ends up wiping both files and Suricata continues to write to http.log.1.
Updated by Matt Jonkman about 12 years ago
Verified. Moving files does not change log output. Deleting the file causes logging to stop.
Updated by Digital Ninja about 12 years ago
Victor's solution on #4 seems to work fine on Ubuntu 12.04/64-bit. Alternatively, logrotate is also working for me with this configuration:
compress
/var/log/suricata/http.log {
rotate 7
daily
copy
postrotate
echo > /var/log/suricata/http.log
chown ids:ids /var/log/suricata/http.log
endscript
}
Updated by Ludovico Cavedon about 12 years ago
Victor Julien wrote:
cp http.log http.log.1 && > http.log
Isn't there a race condition here?
If suricata writes an entry between "cp http.log http.log.1" and "> http.log" you lose it...