Hello,
a simple sample is available in the Configuration Examples
see "Monitor HDD Temperature"
https://mmonit.com/wiki/Monit/ConfigurationExamples#HDDTemp
or "Monitor HDD health status"
https://mmonit.com/wiki/Monit/ConfigurationExamples#HDDHealth
I group messages/alarms in "Error", "Warning", "Info" and "OK" only to
send an alarm to an zentral system. The messages are handled in a simple
shell script only.
>From my point of view, the "if succeeded then" handling is the most
importent part. This will set the whole "check program" to "OK".
> if status > 1 then exec "/usr/local/etc/monit/scripts/zexec.sh 'Info'"
> else if succeeded then exec "/usr/local/etc/monit/scripts/
> zexec.sh 'OK'"
A suggestion only,
Lutz
Appendage:
Sample script
#!/bin/mksh
while read -r line; do
if [[ "$line" = 'CRIT:'* ]]; then
rc=3
elif [[ "$line" = 'WARN:'* ]]; then
rc=2
elif [[ "$line" = 'INFO:'* ]]; then
rc=1
else
rc=0
fi
done <<EOD
$(your command)
EOD
echo "$line"
exit $rc
Am 10.12.25 um 07:56 schrieb Gerrit Kühn:
> Am Tue, 9 Dec 2025 22:03:10 +0100
> schrieb Lutz Mader <[email protected]>:
>
> Hello Lutz,
>
>> if status > 2 then exec "/usr/local/etc/monit/scripts/zexec.sh 'Error'"
>> if status = 2 then exec "/usr/local/etc/monit/scripts/zexec.sh 'Warning'"
>> if status > 1 then exec "/usr/local/etc/monit/scripts/zexec.sh 'Info'"
>> else if succeeded then exec "/usr/local/etc/monit/scripts/
>> zexec.sh 'OK'"
>>
>> The script handle the message and will end with a proper return code.
>> The command output is available in the "last output".
>>
>> last exit value 2
>> last output WARN: tank/syncoid/[long path] newest
>> daily snapshot is 4d 2h 27m 6s old (should be < 2d 12h 0m 0s)
>>
>> A suggestion only,
>
> Thanks for the explanations and the suggestions. This looks very useful,
> it should be possible to write some simple script to cover my use case.
> Before, I was thinking about trying to set an explicit reminder with a
> longer cycles number ("alert [email protected] with reminder on 120 cycles" or
> similar), but the scripted solution looks cleaner and more flexible.
>
> What I do not understand completely yet from your example is how you split
> the actual check and the message generation. How does your actual check
> statement look like in that case (is that still a direct call to sanoid
> --monitor-snapshots, or also a script call?), and how does monit process
> the generated output from the exec script (not being in an check
> statement)?
>
>
> cu
> Gerrit
>
