-
-
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
fail2ban.filterpyinotify Unable to retrieve Watch object warnings in log #2256
Comments
Anyone? |
I have the same complaint using up-to-date Debian "testing" Buster/Sid. I too would be interested to know what's up with it. My entries are just after midnight: |
This warning is written directly from pyinotify module (I suspect if pyinotify missed the file/dir during the log-rotate process). This was indirectly introduced by me in e340d0d to resolve some pyinotify issue (I was hoping to catch some sporadic pyinotify errors), so I set fail2ban logger as pyinotify logger). Well, it is just a WARNING (and I assume one see it only if log-rotation occurs). Of course I can "fix" that:
Therefore at the moment I tend to leave this as it is. |
Thanks for the explanation. It is what I needed, and for my purposes it
is entirely sufficient. I have a suggestion, however:
By way of explanation: I use logcheck (a lot!) and I only suppress log
lines if I have figured out what they mean and I have determined that I
can safely ignore them. That's one of the ways I keep the systems
running smoothly here, and it's a pretty effective technique.
This pyinotify warning sounded too alarming to ignore without
understanding it. I get especially worried when it looks like problem
reports may be lost or somehow hidden from me. (I maintain both
logcheck and fail2ban via a single large, non-redundant Python
dictionary of regular expressions.)
Many times, I have found "warning" messages about which I could
reasonably be expected to do something, in order to restore the system
to (relatively taciturn, as opposed to verbose) good health. Some such
messages are very helpful.
This particular situation, however, is not that kind of thing; it's more
like a message from the system to the developer, and finicky end users
like myself should normally not worry about it. Maybe you can think of a
way for the message to be less worry-inducing, such as adding "(End
users can ignore this.)".
…On 11/19/18 10:54 AM, Sergey G. Brester wrote:
The waning listed should not appear.
This warning is written directly from pyinotify module (I suspect if
pyinotify missed the file/dir during the log-rotate process).
So the question is why it should not appear?
This was indirectly introduced by me in e340d0d
<e340d0d>
to resolve some pyinotify issue (I was hoping to catch some sporadic
pyinotify errors), so I set fail2ban logger as pyinotify logger).
Well, it is just a WARNING (and I assume one see it only if
log-rotation occurs).
Does this message really bother you so?
Of course I can "fix" that:
* either by removing of this log-handler, but I assume if some
errors in pyinotify backend occurred later, we'll not see
corresponding error-related information from pyinotify module
(that otherwise can be logged from there);
* or by injection on pyinotify code to avoid producing this warning,
but IMHO it is too aggressive (too error-prone, can cause unwanted
after-effects in future version of module etc);
* or by request to pyinotify developer
<https://github.com/seb-m/pyinotify> to remove this warning or to
set it to lower log-level. Here is the corresponding line (for
py2.x) -
https://github.com/seb-m/pyinotify/blob/master/python2/pyinotify.py#L1280-L1284
Therefore at the moment I tend to leave this as it is.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2256 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AXalpuVy2UOXcVVHlui2rAekASsMGKI5ks5uwtQqgaJpZM4XYbaR>.
|
Possibly you still did not understand: we don't produce this message in fail2ban - this is logged directly from pyinotify python module (in the line 1283), which is a "foreign" library fail2ban used. I was only responsible for enabling the whole logging from pyinotify (as a result of this you see this warning). |
Thanks for the explanation. Based on what you've said, I'll just adjust my log software to filter those lines out. As far as I'm concerned that's all I was looking for. |
#3027 (comment) shows another possibility to suppress the warning from pyinotify module (fixed coded or via config if this enhancement gets implemented). |
Environment:
Fail2Ban version (including any possible distribution suffixes): Fail2Ban v0.10.2
OS, including release name/version: Ubuntu 18.04 LTS
[X ] Fail2Ban installed via OS/distribution mechanisms
[X ] You have not applied any additional foreign patches to the codebase
Some customizations were done to the configuration (provide details below is so)
The issue:
Lines similar to this appear occasionally in my fail2ban log:
2018-10-11 06:25:06,631 fail2ban.filterpyinotify[451]: WARNING Unable to retrieve Watch object associated to <_RawEvent cookie=0 mask=0x2 name='' wd=5 >
Steps to reproduce
It occurs during the daily logrotate, but it does not happen 100% of the time and I cannot find anything that correlates to when it does happen.
Expected behavior
The waning listed should not appear.
Observed behavior
The warning listed does appear.
Any additional information
Although it happens sporadically it seems that once it occurs, it will recur for some indeterminate amount of time then it will stop with no obvious cause.
Configuration, dump and another helpful excerpts
fail2ban-debug.txt
Any customizations done to /etc/fail2ban/ configuration
dbpurgeage = 7.5d
Changed from the original 86400 seconds.
Relevant parts of /var/log/fail2ban.log file:
preferably obtained while running fail2ban with
loglevel = 4
Relevant lines from monitored log files in question:
N/A
The text was updated successfully, but these errors were encountered: