FILE CONTENT TESTING - rereads the file instead of tailing it

Issue #233 resolved
Whitehat Whitehat
created an issue

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)

  1. Tildeslash 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.

  2. Whitehat Whitehat 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)

  3. Tildeslash 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?

  4. Tildeslash 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 :-)

  5. Log in to comment