I got the fail2ban from epel. There were a number of issues relating to using a log file... logwatch was looking for both fail2ban and fail2ban.log logrotate file fail2ban added looked for fail2ban.log and then reset itself to syslog fail2ban itself went to syslog, over riding its fail2ban.log.
took a while, but I use /var/log/fail2ban now, that finally worked through logrotates and logwatch.
Problem with centos variant of fail2ban:
logrotate causes all 'ban' actions to stop happening. I am pretty sure it stops reading the logs but still functions. Unban actions still keep showing up in the log, but the 'ban' actions just stop. Program is running, but no longer working.
Long searches online show a million others with the same issue. Only way to prevent it seems to be to add a reload or restart in the syslog file. This is undesired due to losing all banned ips listed.
It happens as part of the logrotate. The logrotate file I have changed a few times and recently tried this postrotate /usr/bin/fail2ban-client set logtarget /var/log/fail2ban 1>/dev/null || true endscript
setting the logtarget, which the original called for changing it to syslog and 2>dev/null || true
so what would you do? I imagine when logrotate happens and syslog restarts something is causing fail2ban to stop working properly, but still timing 'unbans'.
This is apparently a bug/problem for almost everyone of all distros. Other than just uninstalling, the only way to make it work would be a restart around 4 every morning, making any long term bans useless.
My last thought is to just throw the /var/log/fail2ban to be rotated by syslog like maillog and the others..and not doing anything special. Maybe it would just work.
I write here because I know there are hundreds of you and someone must have figured out how to make fail2ban work for more than 24 hours without a restart....