After a bit of testing it seems like the github issue actually is the problem. When auth.log gets rotated by logrotate, fail2ban no longer tracks changes to it, and so never takes any actions from that point on. To reproduce this:
1. Set up a server in a VM with sshd and install fail2ban. No config changes should be needed. 2. Run 'fail2ban-client set loglevel 4' to turn on debug logging (it should say "loglevel is DEBUG" or similar). 3. tail -f /var/log/fail2ban.log 4. tail -f /var/log/auth.log 5. ssh to server and enter wrong password. you should see activity in both log files when you do this. 6. Force log rotation: /usr/sbin/logrotate --force /etc/logrotate.conf - this should truncate auth.log 7. Try to ssh with wrong password again. You should still see the auth warning in auth.log but fail2ban will not notice any changes until you restart the fail2ban service. ** Summary changed: - fail2ban fails to ban + fail2ban fails to ban after logrotate -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1406996 Title: fail2ban fails to ban To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fail2ban/+bug/1406996/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
