Skip to content
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

pfSense-pkg-suricata: Delete rotated eve.json log files #387

Closed
wants to merge 2 commits into from
Closed

pfSense-pkg-suricata: Delete rotated eve.json log files #387

wants to merge 2 commits into from

Conversation

johannrichard
Copy link
Contributor

The automatic log removal under suricata_check_dir_size_limit currently does not clean-up the eve.json.* log. This can lead to a situation where the other rotated logs are cleared but the overall directory size can still grow beyond the hard limit.

For example, if eve.json log retention is set to more than a few days and with flow logging enabled: there you can end up with dozens of files that are not cleared in time.

With this change, that shouldn't happen anymore.

This change is especially relevant with respect to changes introduced in #383 that result in large eve.json files if flow is enabled.

johannrichard and others added 2 commits August 7, 2017 08:42
The automatic log removal under `suricata_check_dir_size_limit` does not clean-up the ève.json.*` log files properly. This can lead to a situation where the other rotated logs are cleared but the overall directory size can still grow beyond the hard limit. 

For example, if `eve.json` log retention is set to more than a few days and with `flow` logging enabled: there you can end up with dozens of `32MB` files that are not cleared in time.  

With this change, that shouldn't happen anymore.
@bmeeks8
Copy link
Contributor

bmeeks8 commented Aug 8, 2017

@johannrichard : would you consider also including the code in the patch a user submitted on the Redmine bug site for pfSense here: https://redmine.pfsense.org/issues/7756#change-33404?

He included a nice patch that makes the log cleanup code much smarter, and it also corrects a few oversights. I was just thought it would be efficient to roll all the log cleanup fixes into a single patch.

Thanks,
Bill

@johannrichard
Copy link
Contributor Author

I'm fine with the log cleanup implementation in #389 which is indeed much more comprehensive! I therefore close this request. Thanks, @opoplawski.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants