[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Monit state is not fully saved

From: karen.arutyunov
Subject: Re: Monit state is not fully saved
Date: Sat, 13 Feb 2016 15:51:50 +0300

Hi Martin,

Thank you for the answer regarding the first described behavior. Good to know 
it goes away.

According to the current state of the master branch it seems that Monit still 
don’t save the state on exit in non-daemon mode. Do you know if there are any 
plans to change that as well ?

Best regards,

> On 13 февр. 2016 г., at 15:12, Martin Pala <address@hidden> wrote:
> Hi Karen,
> that problem is fixed in the development version already, snip from changelog:
> --8<--
> Fixed: Issue #316: The "if changed checksum" and "if changed timestamp" tests 
> value
> is persistent across monit restart/reload now, so if the checksum changed 
> while monit
> was stopped or reloading, it will catch the change. Thanks to Duke 
> Bartholomew for fix.
> Fixed: Save the file size, filesystem flags, file/directory/fifo/filesystem 
> permissions,
> network link speed so the "if changed" tests keep the last value across monit 
> restart/reload.
> --8<--
> Best regards,
> Martin
>> On 13 Feb 2016, at 12:48, karen.arutyunov <address@hidden> wrote:
>> Hi,
>> I have just started to evaluate Monit 5.16 and have noticed the following 
>> behaviors.
>> 1. File timestamps are not saved to .monit.state file, so CHECK FILE 
>> statement misses the file timestamp change if it happen between Monit 
>> executions in daemon mode. This somewhat inconsistent with the fact that the 
>> file read position IS saved, so Monit being configured to monitor log file 
>> for error messages can detect those which appeared between Monit executions.
>> 2. If executed in non-daemon mode Monit reads the state from .monit.state 
>> file, but do not save the latest state on exit (unlike the daemon mode). 
>> This make it impossible to use non-daemon mode to monitor logs for specific 
>> messages.
>> Would very much appreciate if someone explain if these behaviors are for 
>> reason, or bugs, or well known but planned to be changed.
>> Best regards,
>> Karen
>> --
>> To unsubscribe:
> --
> To unsubscribe:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]