| Newsgroups |
gmane.comp.monitoring.monit.general |
| Message-ID |
<[email protected]> |
Hello Christos,
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.
We're working on a new Monit release, which will include a fix for the =
problem.
Best regards,
Martin
> 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