only email genuine backup failures

A spurious invocation carries no action for a reader, so mailing it just
trains them to skip past the subject line -- which defeats the point of the
alert. Send mail only when the unit actually reports failure; spurious
triggers still leave their journald record, so they stay greppable and can
still feed a Graylog rule.

Verified both paths: a spurious trigger leaves /var/log/msmtp.log untouched
and logs alert_mail=skipped reason=spurious, while a genuinely failed unit
still composes mail with the FAILED subject.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Bastian de Byl
2026-07-26 20:34:45 -04:00
parent 6e99794d0f
commit 16145fb6bd
@@ -42,6 +42,15 @@ $(journalctl -u "$UNIT" -n 40 --no-pager -o cat 2>/dev/null)"
echo "$body" | logger -t "$TAG" -p "$prio" echo "$body" | logger -t "$TAG" -p "$prio"
# Only genuine failures are worth an email. A spurious invocation carries no
# action for a human, and mailing it trains the reader to ignore the subject
# line -- which defeats the point of having the alert at all. The journald
# record above is kept either way, so spurious triggers stay greppable.
if [ "$state" != "failed" ]; then
logger -t "$TAG" -p daemon.info -- "alert_mail=skipped reason=$state"
exit 0
fi
# Mail is best-effort: if the MTA is not configured the journald record above # Mail is best-effort: if the MTA is not configured the journald record above
# is still the authoritative signal, so never fail the handler on this. # is still the authoritative signal, so never fail the handler on this.
if command -v sendmail >/dev/null 2>&1; then if command -v sendmail >/dev/null 2>&1; then