-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BR]: fail2ban.filterpyinotify: WARNING Unable to retrieve Watch object messages on service shutdown #3496
Comments
In #2256 (comment) I asked about 3 ways how it would "fixable". |
Hmm, I was thinking that perhaps there was something wrong with the way the fail2ban was removing the watch. But perhaps it is really an issue in pyinotify. Though hard to tell at this point. Does this seem like a possibility:
If so, is there some way we can make sure all of the events are processed before deleting the watch? |
Sure, one can retard watch deletion a bit. Just I'm unsure it'd help, because then the handler will be closed earlier and a WatchManager work asynchronously, so after all it should not introduce vice versa situation. |
Same here. Fail2ban version 1.1.0.1, AlmaLinux 8. Installed with:
In fail2ban.log I see that after logrotate:
and random times before and after that has no fail2ban actions:
And one more thing - when I copy systemctl service file with:
in service file contain line: Environment="PYTHONNOUSERSITE=1" and reloading or restart fail2ban via systemctl - fail2ban doesn't start. |
The "issue" is already confirmed... And as one can see still open (since there is no simple solution for that, because the warning is throwing from pyinotify module itself (after we allowed to log from there).
It has nothing to do with the issue here. |
Environment:
The issue:
On service/machine shutdown we see this message in the logs. Similar to #2256 but not related to logrotate. I know it's just a warning but it shows up in logwatch and it seems like during normal operation this shouldn't be generated.
Steps to reproduce
I suspect the use of the recidive jail monitoring /var/log/fail2ban.log may be the trigger, but hard to say. It doesn't happen with every shutdown.
Expected behavior
No WARNINGs
Observed behavior
The text was updated successfully, but these errors were encountered: