#46546 closed defect (fixed)
fail2ban goes idle on nighly logrotate
| Reported by: | joaander@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.3.3 |
| Keywords: | Cc: | fclaire@…, mkae (Marko Käning) | |
| Port: | fail2ban |
Description
fail2ban only has one option for monitoring log files on mac: polling. It has a hardcoded limit of 2 failures (file not found) before it ignores any further input, and it polls every second. Even a modern mac running OS X 10.10 can take 3-4 seconds to rotate logs at midnight. This prevents fail2ban from operating as it should.
Could macports add a patch to fail2ban to increase the number of retries? I've been testing the proposed change and haven't had the jails go idle since I made it. Or do I need to get this change implemented upstream and then get macports to version bump the port?
Attachments (1)
Change History (5)
Changed 10 years ago by joaander@…
| Attachment: | fail2ban-filterpoll.patch added |
|---|
comment:1 Changed 10 years ago by neverpanic (Clemens Lang)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Committed in r131527, but if you could talk to upstream about this and see if there might be a better solution? As I understand it, your patch will only delay the problem until fail2ban has been running for a couple of days, wouldn't it? Or does the counter actually get re-set?
comment:2 Changed 10 years ago by neverpanic (Clemens Lang)
| Cc: | fclaire@… added |
|---|
comment:3 Changed 10 years ago by joaander@…
On line 122, it resets the counter to 0 after finding the file - so this temporary fix should continue working indefinitely (unless a logrotate action takes longer than 20 seconds, which seems unlikely).
I will also submit an issue and/or pull request upstream.
Thanks for the quick turnaround!
Patch that increases the timeout to 20 retries.