Hi,
occassionally determining which file to check takes so long that the file has been modified already after the "files" check started but before the file timestamp is actually checked. Hence the file might have a negative age.
But since the variable where this is stored seems to be unsigned, this causes false positives due to an integer overflow:
red /nf/2019/05/03/201905032050 File was modified 4294967291 seconds ago - should be <360 File was modified 4294967291 seconds ago - should be <960
This probably only happens if the file to check first has to be found using backticks or $(...) -- which may take some time.
In our case the according line in client-local.cfg looks like this:
file:ls -1 $(ls -1d /nf/2???/??/??/ | tail -1)* | tail -1
Timing examples:
$ time ls -1 $(ls -1d /nf/2???/??/??/ | tail -1)* | tail -1 /nf/2019/05/03/201905032055
real 0m0.015s user 0m0.003s sys 0m0.004s
I see several potential solutions in decreasing preference:
A) Don't compare to the check startup time but always to the time at which the file timestamp is checked.
B) Use a signed integer instead of an unsigned integer.
C) Ignore timestamps newer than "now" when comparing with "<".
Actually IMHO the proper fix would be to implement both, A and B.
P.S.: Happens with 4.3.28 installed from Debian Stretch's xymon package. Haven't checked with the 4.3.29 branch, but there was nothing related listed in 4.3.29's Changes file so far.
Kind regards, Axel-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/