85.1.51. pepsi-failure-bouncer

Funnel failed/timeout messages to the bounce stage

Handbuchabschnitt:

1

85.1.51.1.1. Name

pepsi-failure-bouncer - festhängende (failed/timeout) Nachrichten zur Bounce-Stage verschieben.

85.1.51.1.2. Übersicht

pepsi-failure-bouncer [GLOBAL-OPTIONS] [–failed-only | –timeout-only]

pepsi-failure-bouncer [GLOBAL-OPTIONS] –once [–failed-only | –timeout-only]

85.1.51.1.3. Beschreibung

Eine Nachricht, die sich durch die Stage-Pipeline nach dem Ingress bewegt (siehe pepsi-dispatch(1)), landet in einem von zwei terminalen Zuständen, wenn ihre aktuelle Stage aufgibt:

failed

Eine Stage hat fail() aufgerufen oder einen Fehler zurückgegeben, den sie als permanent markiert hat, der Worker hat die Wiederholung eines Fehlers in einer Stage ohne BOUNCE_STAGE aufgegeben, oder die Nachricht hat ihren Worker dreimal zum Absturz gebracht.

timeout

Die Nachricht hat ihren Worker dreimal über [pepsi-dispatch] MAX_RUNTIME hinaus festgehalten.

Die meisten Fehler kommen nie hierher: Der Worker wiederholt sie bis zur MAX_LIFETIME der Stage und übergibt die Nachricht dann selbst an die BOUNCE_STAGE der Stage (siehe pepsi-dispatch(1)).

Der Dispatcher reiht einen failed- oder timeout-Datensatz nie erneut ein, sodass sich solche Nachrichten ohne dieses Programm in pepsi.workqueue ansammeln und dem ursprünglichen Absender nie mitgeteilt wird, dass seine Mail nicht zugestellt wurde. Deshalb führt pepsi.target es aus (siehe Systemd unten).

pepsi-failure-bouncer verschiebt jede festhängende Nachricht zur konfigurierten [pepsi-failure-bouncer] BOUNCE_STAGE und setzt ihren Status auf pending zurück. Der Dispatcher führt dann die Bounce-Stage (pepsi-stage-bounce(1)) aus, die — unter Beachtung des RFC-3461-NOTIFY des Absenders — die Nachricht in eine Zustellungsstatusbenachrichtigung verwandelt und an den Absender zurückleitet.

Es wartet zuerst. Eine Nachricht wird erst verschoben, wenn sie seit [pepsi-failure-bouncer] MIN_AGE gescheitert ist (Standard eine Stunde, gemessen ab state.failed_at, das die Datenbank stempelt, wenn der Datensatz failed/timeout wird): das Zeitfenster des Betreibers, den Fehlschlag zu bemerken und die Nachricht mit pepsi-queue(1) zurückzulegen, bevor ihr Absender benachrichtigt wird. Jede verschobene Nachricht wird als Warnung mit ihrem Absender, der Stage, in der sie scheiterte, und dem festgehaltenen Fehler protokolliert, weil die Bounce-Stage diesen Eintrag durch die DSN ersetzt. Die Stage wird außerdem als state.failed_stage aufbewahrt, die pepsi-stage-bounce(1) in der DSN nennt.

Eine Mailinglisten-Kopie (eine Nachricht mit state.list) wird stattdessen gelöscht, mit derselben Protokollzeile. Ihr Umschlagabsender ist die eigene Bounce-Adresse der Liste, sodass eine DSN die Bounce-Verarbeitung der Liste erreichen und einen Fehler dieses Hosts dem Mitglied anrechnen würde.

Eine Nachricht, die sich bereits an der Bounce-Stage befindet, bleibt unberührt, sodass ein Bounce, der selbst an dieser Stage fehlschlägt, nicht in eine Schleife gerät. Ein Bounce, der nach der Bounce-Stage fehlschlägt (eine Null-Absender-DSN, die nicht weitergeleitet werden konnte), wird trotzdem zurück zur Bounce-Stage verschoben, die ihn einfach verwirft — ein Bounce wird niemals erneut gebounct.

Die erste Regel ist nur der Schutz für einen Schritt; die zweite beendet jede längere Kette, denn eine echte Bounce-Stage schreibt die Nachricht auf einen Null-Absender um, und eine Null-Absender-Nachricht wird verworfen statt erneut gebounct. BOUNCE_STAGE muss also zu einer Bounce-Stage führen. Richten Sie es auf eine Stage, die bloß weiterschaltet, und es gibt überhaupt keinen Fixpunkt — die Nachricht wird weitergeschaltet, schlägt weiter unten erneut fehl und wird erneut zurückgesetzt, in einer Schleife, die die Fehlerbenachrichtigung mit Datenbankgeschwindigkeit antreibt. pepsi-setup(1) schlägt rundheraus fehl, wenn BOUNCE_STAGE überhaupt keine konfigurierte Stage benennt, und warnt, wenn es eine benennt, die nicht direkt pepsi-stage-bounce(1) ausführt; das Zweite ist nur eine Warnung, weil die Option absichtlich eine Routing-Stage benennen darf, die die Bounce-Stage auf einem Zweig erreicht.

Nachdem der Bouncer Datensätze auf pending verschoben hat, benachrichtigt er den workqueue-Kanal selbst, sodass der Dispatcher den Bounce sofort verarbeitet statt erst bei seinem nächsten POLL_INTERVAL-Durchlauf. Er muss das tun: Er läuft außerhalb der Schleife des Dispatchers, und pepsi.workqueue trägt keinen benachrichtigenden Trigger (siehe pepsi-dispatch(1)).

Es verbindet sich über den Abschnitt [pepsi-postgres] mit der gemeinsamen Datenbank und wird durch [pepsi-failure-bouncer] konfiguriert (siehe pepsi.conf(5)). Wenn es als root gestartet wird — eine Root-Shell, ein Cron-Auftrag, eine Unit ohne User= —, läuft es vor dem Verbinden als unprivilegiertes Dienstkonto pepsi weiter, der Rolle, der die Warteschlange gehört: root hat keine eigene PostgreSQL-Rolle, sodass die Verbindung ohne diesen Wechsel abgelehnt würde. Die Konfiguration wird zuerst gelesen, und existiert das Konto pepsi nicht, bleibt die Identität unangetastet und es wird eine Warnung protokolliert. Es ist keine Stage.

85.1.51.1.4. Modi

Ohne --once-Flag läuft pepsi-failure-bouncer als langlebiger Dienst. Es LISTENt auf dem PostgreSQL-workqueue_failed-Kanal — vom Trigger workqueue_failed_notify gefeuert, wann immer ein Schreiber einen Datensatz failed oder timeout macht — und bounct jede Nachricht, sobald sie MIN_AGE alt ist, wobei es für den ältesten wartenden Fehlschlag aufwacht, wenn nicht zuvor eine Benachrichtigung kommt. Beim Start und erneut bei jeder Wiederverbindung fegt es zuerst alle bereits festhängenden Nachrichten durch, sodass nichts übersehen wird, das vor dem Anhängen des Listeners (oder während einer abgebrochenen Verbindung) committet wurde. Es läuft, bis es SIGINT oder SIGTERM empfängt.

Mit –once führt es diesen Durchlauf einmalig über alle derzeit festhängenden Nachrichten aus und beendet sich — die Form für einen manuellen Operator-Lauf und für den ausgelieferten Timer.

85.1.51.1.5. Systemd

pepsi-failure-bouncer.timer führt pepsi-failure-bouncer.service aus, einen –once-Durchlauf unter dem Konto pepsi, zehn Minuten nach dem Systemstart und danach alle zehn Minuten. pepsi.target verlangt den Timer, sodass das Aktivieren des Targets den Durchlauf aktiviert. Eine gescheiterte Nachricht bleibt daher zwischen MIN_AGE und MIN_AGE plus zehn Minuten in der Warteschlange, bevor sie gebounct wird (oder, bei einem Absender, den die Nachricht nicht authentifiziert hat, mit einer Warnung verworfen wird; siehe BOUNCE_UNAUTHENTICATED in pepsi.conf(5)). Um eine Nachricht stattdessen erneut zu versuchen, verwenden Sie innerhalb dieser Zeit set-stage von pepsi-queue(1).

Entwickler und Tester, die gescheiterte Nachrichten zur Diagnose behalten möchten, schalten den Durchlauf ab mit:

systemctl mask --now pepsi-failure-bouncer.timer

Das Maskieren ist nötig, weil pepsi.target einen lediglich deaktivierten oder angehaltenen Timer wieder starten würde. systemctl unmask pepsi-failure-bouncer.timer gefolgt von systemctl start pepsi-failure-bouncer.timer schaltet ihn wieder ein; der nächste Durchlauf bounct dann alles, was in der Zwischenzeit gescheitert ist. Lassen Sie ihn auf einem Rechner, der echte Mail verarbeitet, nicht maskiert.

Keine Unit führt den langlebigen Dienstmodus aus. Eine Installation, die ihn bevorzugt (ein Fehlschlag wird dann binnen Augenblicken statt Minuten gebounct), maskiert den Timer und startet den Dienst aus einer eigenen Unit.

85.1.51.1.6. Optionen

–once

Fegt die jetzt festhängenden Nachrichten durch, die es schon seit MIN_AGE sind, und beendet sich, statt als Dienst zu laufen, der auf neue Fehlschläge lauscht.

–failed-only

Handelt nur an failed-Nachrichten und ignoriert timeout.

–timeout-only

Handelt nur an timeout-Nachrichten und ignoriert failed. Schließt sich mit –failed-only gegenseitig aus.

85.1.51.1.7. Globale Optionen

Diese Optionen können vor oder nach den anderen Flags stehen.

-c FILE, –config FILE

Liest die Konfiguration aus FILE, statt die Standardorte zu durchsuchen.

-L LOGLEVEL, –log LOGLEVEL

Setzt die Log-Ausführlichkeit. LOGLEVEL ist eines von error, warn, info, debug oder trace (Standardwert: info).

-v, –verbose

Zeigt Log-Meldungen aus allen Quellen, einschließlich Drittanbieter-Bibliotheken.

-h, –help

Gibt eine Verwendungsübersicht aus und beendet sich.

-V, –version

Gibt die Version aus und beendet sich.

85.1.51.1.8. Exit-Status

0

Erfolgreicher Abschluss (ein --once-Durchlauf wurde beendet, oder der Dienst fuhr auf ein Signal hin sauber herunter).

1

Ein Fehler ist aufgetreten: eine fehlerhafte Konfiguration, die fehlende erforderliche BOUNCE_STAGE-Option oder eine fehlgeschlagene Datenbankverbindung. Im Dienstmodus ist eine verlorene Datenbankverbindung nicht fatal — sie wird protokolliert und mit Backoff wiederholt.

85.1.51.1.9. Beispiele

Als Dienst ausführen, aus einer eigenen Unit:

pepsi-failure-bouncer -c /etc/pepsi/pepsi.conf

Alles derzeit Festhängende einmalig von Hand bouncen:

pepsi-failure-bouncer -c /etc/pepsi/pepsi.conf --once

Nur die Nachrichten bouncen, die in einen Timeout liefen:

pepsi-failure-bouncer -c /etc/pepsi/pepsi.conf --once --timeout-only

85.1.51.1.10. Siehe auch

pepsi-dispatch(1), pepsi-stage-bounce(1), pepsi-queue(1), pepsi-status(1), pepsi.conf(5), systemd.timer(5)

85.1.51.1.11. Fehler

Melden Sie Fehler an den Pepsi-Issue-Tracker.