Re: Recovery email sent without failure or recovery log entry

Christos Chatzaras <[email protected]> Tue, 14 Jul 2026 08:02:15 +0300
Newsgroups gmane.comp.monitoring.monit.general
Message-ID <[email protected]>
Thank you Martin.

> On 13 Jul 2026, at 23:29, [email protected] wrote:
>=20
> Hello Christos,
>=20
> New issues are not visible on Bitbucket Issues until opened (kind of =
confirmed) by the repository owner - we have opened the issue referenced =
by Lutz now.
>=20
> We're working on a new Monit release, which will include a fix for the =
problem.
>=20
> Best regards,
> Martin
>=20
>=20
>=20
>> On 13. 7. 2026, at 22:02, Christos Chatzaras <[email protected]> =
wrote:
>>=20
>> Hello Lutz,
>>=20
>> The link doesn't work.
>>=20
>>> On 13 Jul 2026, at 09:11, Lutz Mader via This is the general mailing =
list for monit <[email protected]> wrote:
>>>=20
>>> Hello FYI,
>>> based on the post from Christos Chatzaras, 09.07.2026 10:14 CEST,
>>> Recovery email sent without failure or recovery log entry
>>>=20
>>> I open the issue 1154, see
>>> =
https://bitbucket.org/tildeslash/monit/issues/1154/succeeded-email-sent-wi=
thout-a-failure
>>>=20
>>> With a suggestion to fix the problem,
>>> Lutz
>>>=20
>>>=20
>>> Am 11.07.26 um 01:20 schrieb Lutz Mader via This is the general =
mailing
>>> list for monit:
>>>> Hello Christos Chatzaras,
>>>> you are right, based on your test sample I receive "Resource limit
>>>> succeeded" mails only, but no preceding "Resource limit matched" =
mail.
>>>>=20
>>>> Based on Monit 5.35.2, "Resource limit matched" mails are sent =
first and
>>>> if the cpu load is below the usage percentage a "Resource limit
>>>> succeeded" mail is sent, as expected.
>>>>=20
>>>> Nice to see your fix,
>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D296636
>>>>=20
>>>> Lutz
>>>>=20
>>>>=20
>>>> Am 09.07.26 um 19:27 schrieb Christos Chatzaras:
>>>>> For anyone experiencing the same issue, this patch restores the =
behavior of the previous Monit version:
>>>>>=20
>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D296636
>>>>>=20
>>>>>=20
>>>>>> On 9 Jul 2026, at 11:14, Christos Chatzaras <[email protected]> =
wrote:
>>>>>>=20
>>>>>> Hello,
>>>>>>=20
>>>>>> I am using Monit 6.0.0 on FreeBSD 14+.
>>>>>>=20
>>>>>> My configuration includes:
>>>>>>=20
>>>>>> set daemon 30
>>>>>>=20
>>>>>> set alert [email protected] not on { instance, action, =
uptime }
>>>>>>=20
>>>>>> check system $HOST
>>>>>> if cpu usage > 65% for 20 cycles then alert
>>>>>> if cpu usage > 90% for 10 cycles then alert
>>>>>> if loadavg (15min) per core > 1.0 for 10 cycles then alert
>>>>>> if loadavg (5min) per core > 1.5 for 5 cycles then alert
>>>>>> if memory usage > 96% for 10 cycles then alert
>>>>>> if swap usage > 8 GB for 10 cycles then alert
>>>>>> if pageout > 100 per second for 10 cycles then alert
>>>>>> if pageout > 1000 per second for 3 cycles then alert
>>>>>>=20
>>>>>> The log shows only these CPU messages:
>>>>>>=20
>>>>>> Jul  9 10:32:17 server102 monit[42487]: 'server102.example.com' =
cpu usage of 86.2% matches resource limit [cpu usage > 65.0%]
>>>>>>=20
>>>>>> Jul  9 10:32:48 server102 monit[42487]: 'server102.example.com' =
cpu usage of 76.0% matches resource limit [cpu usage > 65.0%]
>>>>>>=20
>>>>>> There is no CPU recovery message in the Monit log.
>>>>>>=20
>>>>>> However, at the next cycle I received this email:
>>>>>>=20
>>>>>> Resource limit succeeded
>>>>>>=20
>>>>>> Description:
>>>>>> cpu usage check succeeded [current cpu usage =3D 30.6%]
>>>>>>=20
>>>>>> I did not receive any failure email, and the Postfix logs contain =
only the recovery email.
>>>>>>=20
>>>>>> How can Monit send a 'Resource limit succeeded' email when:
>>>>>>=20
>>>>>> 1. The CPU condition was above 65% for only two cycles, not the =
required 20 cycles.
>>>>>> 2. No failure email was sent.
>>>>>> 3. No recovery message was written to the Monit log.
>>>>>>=20
>>>>>> Does 'matches resource limit' only mean that the current sample =
matched the condition, or can it change the shared resource event state =
before the 20-cycle threshold is reached?
>>>>>>=20
>>>>>> Could this be related to having multiple CPU, load average, =
memory, swap, and pageout rules under the same `check system` service?
>>>>>>=20
>>>>>> Thank you.
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>=20
>>=20
>=20
>=20