- edited description
FILE CONTENT TESTING - rereads the file instead of tailing it
trying to tail /var/log/kern log file with monit. On every monit restart - file is read from the beginning, but documentations states "On startup the read position is set to the end of the file and Monit continues to scan to the end of the file on each cycle." Please fix monit not to reread the whole file on every restart, it causes many false alarms and actions This issue is reproducible only if rule is not in a monit state file
Comments (10)
-
reporter -
reporter - attached patch.diff
Quick fix attached. I do not know C, sorry if this patch does something wrong
-
repo owner Hello, we're not able to reproduce the problem.
The file position and inode number of the monitored file are recorded in monit statefile (by default stored in ~/.monit.state, can be customized using "set statefile" statement).
When monit is restarted, it restores the read position and check the inode number - if either the inode number changed (i.e. file was replaced) or the size shrunk, monit resets the position to start of the file.
Which platform and filesystem it is? Please can you post related monit configuration?
You can run monit in debug mode (using "-vI" options) to get more data about the test.
-
reporter but when monit is installed for the first time, it reads the file from the beginning, not from the end. It can be a 10G file it will have to parse. When some action is taken basing of match results - just deploying monit to all servers can result in production failure as it will find some old records in the log file and restart service on every server. Also when modifying monit rules - sometimes I have to remove the state flle, because new rules are not applied properly upon monit restart. So I don't see any reason why this bug can't be fixed. Please see the attached patch, I have monit on hundreds of servers with this patch, no problems (but still please double check it, i'm not a C programmer)
-
repo owner sometimes I have to remove the state flle, because new rules are not applied properly upon monit restart
Isn't this the root problem then? Because if you remove the state-file then Monit will of course forget its last read position. Could you explain in more detail what the problem is that causes you to have to remove the state-file?
-
repo owner - marked as proposal
-
repo owner So this is what we will do: If there is no state-file, Monit will read to EOF first, otherwise it will restore to the read-position in the state-file.
Your 10 GB log file example makes for a good point, and by modifying to this behaviour, if the state-file was removed for some reason, you won't get a bunch of old alerts. We will also keep the function where we restore to the last read-position, because on machine boot, if a a problem occurs and is logged before Monit is started, Monit can then report this, which it cannot if we always seek to the end of files on startup. Thanks for bringing this situation up :-)
-
reporter If there is no state-file, Monit will read to EOF first, otherwise it will restore to the read-position in the state-file.
Great, thank you
-
repo owner - changed status to resolved
fix Issue
#233: The content match test will skip existing content of the file the first time the file is added to Monit→ <<cset ee0fe7d29b2e>>
-
repo owner - removed version
Removing version: 5.14 (automated comment)
- Log in to comment