How to properly handle generic weekly logrotate? I'm seeing VERY early unbans :(

[MrPeteH]

My system is probably pretty typical. Weekly logrotate on all logs by default.
I've tracked down an issue of spurious early unbans to match that.

I see @sebres advice on using fail2ban-client reload <jailname> in postrotate.

What about across the board on all logs? Would fail2ban-client reload accomplish this?

[sebres]

I've tracked down an issue of spurious early unbans to match that.

Impossible, because an unban has nothing to do with rotation or some other changes on logs or journals.
Fail2ban will bans for bantime specified for the jail starting from time of last finding that caused the ban (not the time when ban happens but the time retrieved from timestamp of message of last failure) - so it can distinguish if one has a timing issues like wrong datepattern caused incorrect TZ, or retarded logging (e. g. web server may log request time but write the message to the log firstly by response).
The only way one can get earlier unbans would be manual stop of jail or fail2ban, but they will be restored after (re)start...
Or manual unban using either fail2ban-client unban ... or fail2ban-client set <JAIL> unbanip ....

Either way there is no association with filter (monitoring the log) at all and therefore no relation to logrotation, by any stretch of the imagination.

I see @sebres advice on using fail2ban-client reload <jailname> in postrotate.

Nope. This advice was probably specifical for the case where the logs will be not found after rotation for whatever reasons or some other obscure situation. Anyway it is hard to say without the context, but it is definitely not about early unbans.
Usual logrotation doesn't expect any action with fail2ban-client.

[MrPeteH]

@sebres I am a bit confused about your answer:

• You note that bantime is based on "time retrieved from timestamp of message of last failure"
• Yet somehow this cannot be affected by log rotation?

Log rotation tends to remove "timestamp of message of last failure"... since the log file gets cleared.

So how does that not affect f2b?

[sebres]

1. For the particular IP 3 attempts are logged and therefore found (matched in filter) by fail2ban, what by maxretry = 3 results to the ban, with the end of ban equals to begin of ban (rather the time of last found failure) + current bantime.
2. If the log gets rotated, the log isn't cleared, it is renamed and new log file created instead. Then fail2ban (as it detects log rotation automatically) starts to monitor from scratch (so seeks to begin of file and starts to process new messages in this log).
3. That all does not affect already banned tickets at all - everything what got banned before rotation, remains banned up to its end of ban of IP (see p.1).
4. I already wrote possible reasons for the earlier unban in my first answer.

Thinking a bit about it, I can imagine still one possibility for unbans (well basically bulk unban then) - if the log rotation in postrotate doing something like fail2ban-client restart $jail (note restart not a reload) for whatever reason… but then as already said it will flush all IP immediately, but after restart it will restore them back (which is also logged in fail2ban.log) unless norestored is specified for the banning action.
However as already said in my first answer, neither reload nor (and still worce) restart is normally expected - fail2ban regularly detect rotation without restart or reload, excepting the case where a log-file has completely new name (like timestamp).
But also in this case instead of restart better would be to create a link to some fixed name in the postrotate.