From 16145fb6bdde55a93b45e4c617fdab053cf56736 Mon Sep 17 00:00:00 2001 From: Bastian de Byl Date: Sun, 26 Jul 2026 20:34:45 -0400 Subject: [PATCH] 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) --- .../templates/nextcloud/nextcloud-backup-alert.sh.j2 | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/ansible/roles/podman/templates/nextcloud/nextcloud-backup-alert.sh.j2 b/ansible/roles/podman/templates/nextcloud/nextcloud-backup-alert.sh.j2 index 1e72623..9598b8e 100644 --- a/ansible/roles/podman/templates/nextcloud/nextcloud-backup-alert.sh.j2 +++ b/ansible/roles/podman/templates/nextcloud/nextcloud-backup-alert.sh.j2 @@ -42,6 +42,15 @@ $(journalctl -u "$UNIT" -n 40 --no-pager -o cat 2>/dev/null)" 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 # is still the authoritative signal, so never fail the handler on this. if command -v sendmail >/dev/null 2>&1; then