-
Notifications
You must be signed in to change notification settings - Fork 1.6k
util-logopenfile: Add log rotation thread to rotate during zero-traffic periods #14343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
NOTE: This PR may contain new authors. |
|
Thanks for the conribution, could you check the CI failure ? (SV test about a big dataset) |
9c8331f to
d7c44a3
Compare
|
NOTE: This PR may contain new authors. |
…iods
Description
Fixes time-based log rotation reliability by ensuring rotation checks occur even during periods with no log traffic. Previously, log files would only rotate when writes occurred, causing unpredictable rotation timing during zero-traffic periods.
Main changes:
- Background rotation thread: Periodically triggers rotation checks by calling Write("", 0) on registered contexts which helps during zero-traffic periods
- Fixed double rotation bug: Ensured rotate_time is updated for both rotation_flag and interval-based rotations
- Registration system: Added RegisterTimeBasedLogRotation() to manage contexts requiring time-based rotation checks
- Skip I/O for empty buffers: Modified write functions to perform I/O only when buffer_len > 0, allowing rotation checks without actual writes
The solution reuses existing rotation mechanisms without duplicating logic, ensuring compatibility with all current rotation features (SIGHUP, rotate-interval, filename patterns).
Ticket: OISF#8115
d7c44a3 to
7ea7061
Compare
|
Hi @Abhijeet94 , there seems to be quite a bit of overlap with this work that was merged in 8.0: #12527. Can that be used/extended address the issue? |
|
NOTE: This PR may contain new authors. |
Hi @victorjulien , it seems like the other PR is more about flushing of in memory data to disk rather than dealing with file close/log rotation. These two things seem to be independent since former can be required without any log rotation and log rotation may need to be triggered even if there is nothing new to flush. I checked if there is something that can be re-used. The other PR introduces a function Let me know if you think otherwise, thank you! |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #14343 +/- ##
=======================================
Coverage 84.20% 84.21%
=======================================
Files 1012 1012
Lines 261769 261804 +35
=======================================
+ Hits 220415 220470 +55
+ Misses 41354 41334 -20
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
|
@jlucovsky any thoughts on this? In my mind both efforts revolve around doing house keeping task at some interval. I'm wondering if we can just expand the flush logic to issue the "flush packets" to do more than only flush, but also trigger rotation and possibly other things in the future. |
|
Let me make an attempt to re-use the housekeeping thread now that I know that I can refactor to increase its scope considerably. |
…iods
Consolidates rotation (1s) and flush (configurable) into single maintenance
thread. Rotation via Write("", 0) on registered contexts with I/O skipped
for empty buffers. Fixes rotate_time update for all rotation types.
Redmine Ticket: 8115
ca5df9e to
823c31c
Compare
|
Do you know why the approval workflows are not running? Previously they used to start within a few hours. After my recent commit it hasn't started in a day |
We're all at suricon so paying less attention to github this week. I'll have a look now. |
|
NOTE: This PR may contain new authors. |
|
"Fixed double rotation bug: Ensured rotate_time is updated for both rotation_flag and interval-based rotations" This should go into it's own commit. |
|
I've set the PR to draft as the git history is messy and in general we need a new PR when feedback is implemented. |
| // Threaded eve.json identifier | ||
| static SC_ATOMIC_DECL_AND_INIT_WITH_VAL(uint16_t, eve_file_id, 1); | ||
|
|
||
| // Log rotation globals |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we reuse / update output.cs
static SCMutex output_file_rotation_mutex = SCMUTEX_INITIALIZER;
TAILQ_HEAD(, OutputFileRolloverFlag_) output_file_rotation_flags =
TAILQ_HEAD_INITIALIZER(output_file_rotation_flags);There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so (please correct me if I am wrong!). There are several log_ctx in the system. Some are configured to use rotation flag, some are using rotate interval only, some both, some none. The log_ctxs that use rotation flag are kept in the output_file_rotation_flags. But the issue of "Log rotation doesn't work during zero traffic" can happen with any kind of log_ctx.
So I think the list of output_file_rotation_flags will be separate from the one that would hold which ones need log rotation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are injecting a pseudo packet to rotate as per below comment, I think we may be able to do without log_rotation_list as well. I will check that part.
| LogFileCtx *ctx = log_rotation_list; | ||
|
|
||
| while (ctx != NULL) { | ||
| ctx->Write("", 0, ctx); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would still want to consider reusing more of the flush logic, so instead of flushing from the side here use the same inject flush packet logic so that the thread that owns the file can do the rotate itself
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am trying to understand the code for that but I am not sure how the flush itself is working.
In output.c, the FlushFunc inside typedef struct RootLogger_ never seems to get initialized. Further, module->PacketFlushFunc never seems to be used in the code. Am I missing something? Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jlucovsky can you help explain things?
Description
Fixes log rotation reliability by ensuring rotation checks occur even during periods with no log traffic. Previously, log files would only rotate when writes occurred, causing unpredictable rotation timing during zero-traffic periods.
This implementation consolidates log maintenance operations (rotation and flush) into a single unified thread, improving efficiency and maintainability.
Main Changes
Unified maintenance thread: Consolidates rotation and flush operations into a single
log-maintenancethread that:Write("", 0)on registered contextsheartbeat.output-flush-interval(if enabled)Registration system: Added
RegisterContextForLogRotation()to manage contexts requiring rotation checks, with a linked list tracked vialog_rotation_nextpointersSkip I/O for empty buffers: Modified write functions to perform I/O only when
buffer_len > 0, allowing rotation checks without actual writesFixed double rotation bug: Ensured
rotate_timeis updated for bothrotation_flagand interval-based rotationsArchitecture
The solution reuses existing rotation mechanisms without duplicating logic, ensuring compatibility with all current rotation features (SIGHUP, rotate-interval, filename patterns). The heartbeat thread to flush is re-used to trigger log rotation as well.
Ticket
https://redmine.openinfosecfoundation.org/issues/8115
Make sure these boxes are checked accordingly before submitting your Pull Request -- thank you.
Contribution style:
https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html
Our Contribution agreements:
https://suricata.io/about/contribution-agreement/ (note: this is only required once)
Changes (if applicable):
(including schema descriptions)
https://redmine.openinfosecfoundation.org/projects/suricata/issues