Fail2ban monitoring empty files

What type of hardware are you using: Raspberry Pi 3, 4+
What YunoHost version are you running: 12.1.39
How are you able to access your server: The webadmin
SSH
Are you in a special context or did you perform specific tweaking on your YunoHost instance ?: nothing special

Describe your issue

Hi,
my configuration is the following:
yunohost:
repo: stable
version: 12.1.39
yunohost-admin:
repo: stable
version: 12.1.14
yunohost-portal:
repo: stable
version: 12.1.2
moulinette:
repo: stable
version: 12.1.3
ssowat:
repo: stable
version: 12.1.1

I want to personalise fail2ban and adding new rules. Searching for logs files location, I discover in /var/log/nginx/ that there are access.log, error.log etc… but there size is 0 and the files access.log.1, error.log.1 are gradually growing in size. Does my logrotate service running correctly?
More, fail2ban monitores the empty files.
How can I correct all that?

Share relevant logs or error messages

sudo ls -al /var/log/nginx/
total 24128
drwxr-xr-x+ 2 root adm 4096 May 17 12:44 .
drwxr-xr-x 17 root root 4096 May 17 00:00 ..
-rw-r----- 1 www-data adm 0 May 10 00:00 access.log
-rw-r----- 1 www-data adm 4011431 May 17 17:28 access.log.1
-rw-r----- 1 www-data adm 1072011 May 9 18:17 access.log.2.gz
-rw-r----- 1 www-data adm 517890 Mar 20 06:24 access.log.3.gz
-rw-r----- 1 www-data adm 66655 Feb 17 20:14 access.log.4.gz
-rw-r----- 1 www-data adm 0 May 10 00:00 error.log
-rw-r----- 1 www-data adm 72205 May 17 14:27 error.log.1
-rw-r----- 1 www-data adm 32258 May 9 18:10 error.log.2.gz
-rw-r----- 1 www-data adm 20628 Mar 20 06:09 error.log.3.gz
-rw-r----- 1 www-data adm 3467 Feb 17 20:10 error.log.4.gz

…

Is your server always running, or is it shut down from time to time?

Usually it is running all the time but I restart it a week ago for a kernel update (That’s a RPi at home).

Can you run and share the output of sudo logrotate -d /etc/logrotate.d/nginx ?

sudo logrotate -d /etc/logrotate.d/nginx

warning: logrotate in debug mode does nothing except printing debug messages!  Consider using verbose mode (-v) instead if this is not what you want.

reading config file /etc/logrotate.d/nginx
Reading state from file: /var/lib/logrotate/status
Allocating hash table for state file, size 64 entries
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state

Handling 1 logs

rotating pattern: /var/log/nginx/*.log  after 1 days (14 rotations)

empty log files are not rotated, old logs are removed
considering log /var/log/nginx/access.log
Now: 2026-05-17 20:01
Last rotated at 2026-05-10 00:00
log does not need rotating (log is empty)
considering log /var/log/nginx/error.log
Now: 2026-05-17 20:01
Last rotated at 2026-05-10 00:00
log does not need rotating (log is empty)
...
not running prerotate script, since no logs will be rotated
not running postrotate script, since no logs were rotated

half an hour later, we can see that the access.log.1 file is growing:

-rw-r----- 1 www-data adm 0 May 10 00:00 access.log
-rw-r----- 1 www-data adm 4030979 May 17 20:22 access.log.1
-rw-r----- 1 www-data adm 1072011 May 9 18:17 access.log.2.gz
-rw-r----- 1 www-data adm 517890 Mar 20 06:24 access.log.3.gz
-rw-r----- 1 www-data adm 66655 Feb 17 20:14 access.log.4.gz

Can you try sudo invoke-rc.d nginx rotate ?

Here is the result:

sudo invoke-rc.d nginx rotate
invoke-rc.d: policy-rc.d denied execution of rotate.

Thanks for your help @otm33 !

Solved ?

No unfortunately

Can you share sudo cat /usr/sbin/policy-rc.d?

sudo cat /usr/sbin/policy-rc.d

#!/bin/bash
[[ “$1” =~ “nginx” ]] && exit 101 || exit 0

This issue seems related to amigration from bookworm.
Can you try first this and share the output ?
yunohost tools regen-conf nginx -h

sudo yunohost tools regen-conf nginx -h

usage: yunohost tools regen-conf [NAME …] [-h] [-d] [-f] [-n] [-p]

Regenerate the configuration file(s)

sorry : sudo yunohost tools regen-conf nginx -n

I remember last february, fail2ban was working correctly, it blocks a user one time.

I tried: sudo yunohost tools regen-conf nginx -n

[no output]

No output ?
So let’s try this

sudo nano /usr/sbin/policy-rc.d

Comment out the line

# #!/bin/bash
# [[ "$1" =~ "nginx" ]] && exit 101 || exit 0

and retry

sudo invoke-rc.d nginx rotate

I comment, and then:

sudo invoke-rc.d nginx rotate
Re-opening nginx log files: nginx.

The result seems very good!

sudo lsof /var/log/nginx/access.log
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 1201 root 3w REG 8,2 0 126792 /var/log/nginx/access.log
nginx 1202 www-data 3w REG 8,2 0 126792 /var/log/nginx/access.log
nginx 1203 www-data 3w REG 8,2 0 126792 /var/log/nginx/access.log
nginx 1204 www-data 3w REG 8,2 0 126792 /var/log/nginx/access.log
nginx 1205 www-data 3w REG 8,2 0 126792 /var/log/nginx/access.log

sudo lsof /var/log/nginx/access.log.1

[no output]

:+1: !