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