Can't tail -f on nginx access.log with fail2ban running

I did a quick setup of fail2ban using the provided regex just to get it up and running and I can no longer tail -f /opt/nginx/logs/access.log when the fail2ban service is running I can view the file static but not with live updates I'm supposed to get with the -f switch

fail2ban normally does not interfere with tail -f on an Nginx access log. It only reads the log file to monitor entries and does not place a lock on the file that would stop tail from working.

Here are a few things worth checking:

Verify how tail -f behaves

Start by running:

tail -f /opt/nginx/logs/access.log

From another terminal, generate a request:

curl http://localhost/

If the request is written to the log and visible with commands like cat or tail -n, but does not appear in the active tail -f session, the issue may be related to log rotation or the way the log file is being updated.

Try using tail -F

If the log file is rotated, renamed, or recreated, tail -f can continue watching the old file descriptor and miss new entries.

Use:

tail -F /opt/nginx/logs/access.log

The -F option follows the filename and automatically reconnects if the file is replaced.

Check the Fail2ban backend

Fail2ban can use different backends such as polling, pyinotify, or systemd.

To see which backend is active:

fail2ban-client get <jail-name> backend

While this usually does not affect tail, checking the backend can help narrow down the cause.

Check which processes have the log open

Run:

lsof /opt/nginx/logs/access.log

This will show all processes currently using the log file and help confirm whether Nginx, Fail2ban, and tail are looking at the same file.

Check for log rotation

If the log file is being replaced, compare its inode before and after new requests:

ls -li /opt/nginx/logs/access.log

If the inode changes, tail -f may still be attached to the old file while Nginx and Fail2ban are using the new one.

Summary

Fail2ban is unlikely to be the reason tail -f stops showing new log entries. In most cases, the problem is caused by log rotation, file replacement, or tail following an outdated file descriptor. A good first step is to try tail -F, then check the inode and open file descriptors to confirm that all processes are referencing the same log file.