8. Fehlersuche

Beginnen Sie mit zwei Befehlen; die meisten Probleme zeigen sich in einem von ihnen:

pepsi-status
journalctl -u 'pepsi-*' -p warning --since '1 hour ago'

Pepsi betreiben erklärt die Logs und was pepsi-status meldet. Die folgenden Probleme sind diejenigen, auf die frühe Installationen am häufigsten gestoßen sind.

8.1. Häufige Probleme

8.1.1. Es kommt keine Mail an

• Ein anderer MTA belegt Port 25. Debian installiert standardmäßig einen. systemctl start pepsi.target schlägt dann fehl, und systemctl status pepsi-ingress.socket zeigt Result: resources. ss -ltnp 'sport = :25' nennt das Programm; halten Sie es an und deaktivieren Sie es (siehe Installation, „Migration von einem vorhandenen Mailserver“).

• DNS oder die Firewall. Der MX-Eintrag der Domain muss diesen Host nennen, und Port 25 muss aus dem Internet offen sein. pepsi-setup -c /etc/pepsi/pepsi.conf run gibt die erwarteten Einträge aus und prüft die veröffentlichten.

• Pepsi weist die Nachricht ab. Der Server des Absenders erhält den Grund, und ebenso das Journal von pepsi-ingress. Die üblichen: 550 5.1.1 für eine Adresse, an die nichts auf diesem Host zustellt (siehe VERIFY_RECIPIENTS in pepsi-ingress(1)); 550 für ein eindeutiges DMARC-Scheitern unter DMARC_ENFORCE; 452 4.3.1, wenn die Warteschlange oder die Platte voll ist (siehe MAX_QUEUE_ROWS und MIN_FREE_SPACE in pepsi.conf(5)).

8.1.2. Ausgehende Mail wird nicht zugestellt

pepsi-status listet die an jeder Stage wartenden Nachrichten auf. Nachrichten, die an einer Relay-Stage paused bleiben, werden erneut versucht; pepsi-queue list ID --state-only zeigt die letzte Antwort des entfernten Servers. Häufige Ursachen:

• Der ausgehende Port 25 ist gesperrt. Viele Hosting- und Privatkundenanbieter sperren ihn. Leiten Sie stattdessen über einen Smarthost (pepsi-setup --wizard).

• Der empfangende Server weist die Mail ab oder legt sie als Spam ab. Prüfen Sie, dass die SPF-, DKIM- und DMARC-Einträge, die pepsi-setup run ausgibt, veröffentlicht sind und dass die Adresse des Hosts einen Reverse-DNS-Namen hat, der zu [pepsi-ingress] HOSTNAME passt.

8.1.3. sendmail oder Cron-Mail scheitert mit „temporary failure“

pepsi-sendmail übergibt Mail über /run/pepsi/submission.sock an pepsi-ingress und endet mit Status 75 (vorübergehender Fehler), wenn dort niemand antwortet. Prüfen Sie, dass pepsi.target läuft. Wurde /run/pepsi von Hand gelöscht, legt systemd-tmpfiles --create es mit den richtigen Berechtigungen neu an; starten Sie danach pepsi-ingress neu.

8.1.4. Ein Programm endet mit Status 78

Das Datenbankschema ist nicht das, mit dem das Programm gebaut wurde, typischerweise in den Minuten nach einem Upgrade, bevor pepsi-setup schema gelaufen ist. Die Meldung nennt die Abhilfe; Upgrade enthält die Tabelle der Fälle. Die Dienste versuchen es von selbst erneut und kommen zurück, sobald das Schema passt.

8.1.5. „permission denied“ von der Datenbank

Die Berechtigungen der Datenbankrollen setzt pepsi-setup. Führen Sie nach dem Wiederherstellen einer Datenbank oder nach einer Änderung der Rollen von Hand erneut pepsi-setup -c /etc/pepsi/pepsi.conf run aus.

8.1.6. Nachrichten in failed oder timeout

Die meisten Fehler beenden eine Nachricht überhaupt nicht, weil an ihnen dieser Host schuld ist und nicht die Nachricht:

• Eine verlorene Datenbankverbindung: Die Nachricht wird pausiert und alle 30 Sekunden erneut versucht, bis die Datenbank wieder da ist, und jeder Versuch wird unter pepsi-dispatch protokolliert („lost its database connection“).

• Jeder andere Fehler, den eine Stage meldet — ein Schlüssel, eine Vorlage, eine Map oder ein Vertrauensspeicher, die sich nicht lesen lassen, ein Helper, der sich nicht starten lässt, eine abgelehnte Datenbankanweisung, ein Dienst, der nicht antwortet: Die Nachricht bleibt an ihrer Stage paused, mit dem Fehler in state.last_error, und wird nach einer Minute, dann in sich verdoppelnden Abständen bis zu einer Stunde erneut versucht, für das MAX_LIFETIME der Stage (120 Stunden, sofern nicht anders konfiguriert). Die Stage protokolliert jede Wiederholung („failed at stage ‚…‘ (attempt N); retrying in …s“). Beheben Sie die Ursache, und die Warteschlange leert sich von selbst; pepsi-status zeigt die wartenden Nachrichten in der Zwischenzeit an. Läuft MAX_LIFETIME ab, geht die Nachricht an die BOUNCE_STAGE der Stage, deren DSN dem Absender mitteilt, dass ein lokaler Fehler fortbestand.

• Eine Stage, deren Konfiguration sich nicht mehr parsen lässt, startet gar nicht erst: Der Dispatcher protokolliert „the worker refused to start“, behält die Nachrichten in der Warteschlange und versucht es alle paar Sekunden erneut. Die eigene Log-Zeile der Stage sagt, was nicht stimmt.

• Ein Worker, der abstürzt oder über MAX_RUNTIME hinaus hängt, pausiert die Nachricht, an der er gearbeitet hat, und versucht sie eine Minute später erneut; erst beim dritten Mal wird die Nachricht aufgegeben.

• Ein Milter, der eine Nachricht immer wieder zurückstellt oder nicht erreichbar ist, hält sie ebenfalls für MAX_LIFETIME fest und bounct sie dann (oder belässt sie failed) — er verwirft sie nie über das REJECT_STAGE des Filters. Ein Milter, der nur einige Empfänger zurückstellt, hält nur deren Kopie fest, als eigene paused-Nachricht in der Milter-Stage, während die übrigen zugestellt werden.

Eine Nachricht endet nur dann in failed, wenn eine Stage einen Mangel in der Nachricht selbst gefunden hat, wenn einer Stage ohne BOUNCE_STAGE die Wiederholungen ausgegangen sind oder wenn sie ihren Worker dreimal zum Absturz gebracht hat; und in timeout, wenn sie ihn dreimal hat hängen lassen. state.failure_class und state.last_error sagen, welches davon und warum.

Zustellfehler vom nächsten Server (ein ablehnender oder nicht erreichbarer MX, eine DNS-Abfrage mit Zeitüberschreitung) werden von den Relay-Stages selbst auf dieselbe Weise erneut versucht. Eine fehlgeschlagene Nachricht erneut zu versuchen, lohnt sich dennoch oft, sobald die Ursache behoben ist.

pepsi.target führt alle zehn Minuten pepsi-failure-bouncer --once aus (pepsi-failure-bouncer.timer). Es verschiebt jede Nachricht, die seit [pepsi-failure-bouncer] MIN_AGE (eine Stunde, sofern nicht anders konfiguriert) in failed oder timeout ist, zu der Stage, die [pepsi-failure-bouncer] BOUNCE_STAGE benennt (bounce in der ausgelieferten Konfiguration und in der des Assistenten), die dem Absender eine Zustellungsstatusbenachrichtigung schickt, wie es sein NOTIFY verlangt, und protokolliert jede mit dem Grund. Ein Absender, dessen Domain die Nachricht nicht authentifiziert hat, erhält unter BOUNCE_UNAUTHENTICATED = drop keine Benachrichtigung, und die Nachricht wird gelöscht, mit einer Warnung im Log der Bounce-Stage. Die Kopie eines Mailinglisten-Beitrags wird gelöscht statt gebounct. Eine gescheiterte Nachricht bleibt also etwa MIN_AGE lang in der Warteschlange; um sie erneut zu versuchen statt sie zu bouncen, handeln Sie innerhalb dieser Zeit:

pepsi-queue list --status failed          # which messages, at which stage
pepsi-queue list 1234 --state-only        # why: state.last_error, state.bounce, …
pepsi-queue set-stage 1234 relay          # retry it from a stage of your choice
pepsi-failure-bouncer --once              # or bounce all of them now
pepsi-queue delete 1234                   # or discard it

Die Optionen von list stehen nach dem Wort list. systemctl list-timers pepsi-failure-bouncer.timer zeigt, wann der nächste Durchlauf stattfindet, und journalctl -u pepsi-failure-bouncer, wie viele Nachrichten jeder Durchlauf verschoben hat.

8.1.7. Gescheiterte Nachrichten zur Diagnose aufbewahren

Auf einem Entwicklungs- oder Testrechner ist eine gescheiterte Nachricht meist genau das, was Sie sich ansehen möchten, und ein Bounce eine Stunde später vernichtet sie. Erhöhen Sie MIN_AGE oder schalten Sie den Durchlauf dort ab:

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

mask statt disable: pepsi.target verlangt den Timer, daher startet ein lediglich deaktivierter oder angehaltener Timer mit dem Target wieder. Gescheiterte Nachrichten bleiben dann in der Warteschlange, bis Sie sie wie oben erneut versuchen, bouncen oder löschen. Um den Durchlauf wieder einzuschalten:

systemctl unmask pepsi-failure-bouncer.timer
systemctl start pepsi-failure-bouncer.timer

Der nächste Durchlauf bounct dann alles, was in der Zwischenzeit gescheitert ist; löschen Sie vorher, was nicht gebounct werden soll. Lassen Sie den Timer auf einem Server, der echte Mail verarbeitet, nicht maskiert: Über eine gescheiterte Nachricht erfährt dann niemand etwas, weder der Absender noch Sie, es sei denn, Sie beobachten problem_total (siehe Überwachung).

pepsi-failure-bouncer kann stattdessen als Dienst laufen, der jede gescheiterte Nachricht sofort bounct. Für diesen Modus wird keine Unit ausgeliefert; maskieren Sie den Timer, bevor Sie ihn aus einer eigenen Unit starten.

8.2. Häufig gestellte Fragen

Führt Pepsi ein Protokoll darüber, wer wem gemailt hat?

Standardmäßig nicht. Eine zugestellte Nachricht wird aus der Warteschlange gelöscht, und nur das Journal erwähnt sie. [pepsi] MAIL_LOG schaltet einen Eintrag je Nachricht ein; lesen Sie zuerst die Warnung in pepsi.conf(5).

Wo ist die Warteschlange?

In PostgreSQL, Tabelle pepsi.workqueue. pepsi-queue und pepsi-status sind die unterstützten Wege, sie anzusehen; ein einfaches SELECT funktioniert ebenfalls.

Wie sehe ich die Pipeline, die dieser Host betreibt?

pepsi-config dump gibt die effektive Konfiguration aus (--origin zeigt zusätzlich, welche Einstellungen die Datenbank überschreibt), und pepsi-setup run gibt für jede Domain aus, wie Empfänger geprüft werden. Der Assistent erklärt die Pipelines, die der Assistent aufbaut.

Kann ich zum vorherigen Release zurückkehren?

Nicht an Ort und Stelle: Das Schema wird nur vorwärts migriert. Stellen Sie die vor dem Upgrade angelegte Sicherung wieder her und installieren Sie dann die älteren Pakete; siehe Upgrade.

Kann Pepsi neben Postfix oder Exim laufen?

Nicht beide auf Port 25. Pepsi kann die Konfiguration des anderen Servers importieren; siehe Installation.

Warum zeigt die Konsole alles schreibgeschützt an?

Das Paket pepsi-httpd-admin, das die Änderungen der Konsole ausführt, ist nicht installiert, oder sein Socket läuft nicht; siehe Debian-Pakete.

8.3. Deinstallation

Debian-Pakete. apt remove pepsi hält die Dienste an und entfernt die Programme; Konfiguration, Schlüssel, die Datenbank und die Dienstkonten bleiben, sodass eine spätere Installation dort weitermacht, wo sie aufgehört hat. apt purge pepsi entfernt den Rest dessen, was das Paket installiert hat, behält aber absichtlich weiterhin die Konfiguration, die Datenbank, die Schlüssel, die Wallets und die Konten und gibt die Befehle aus, die sie entfernen. Diese lauten, als root:

runuser -u postgres -- dropdb pepsi
rm -rf /var/pepsi /var/lib/pepsi-wallets /etc/pepsi
for u in pepsi pepsi-ingress pepsi-httpd pepsi-owner pepsi-config \
         pepsi-helper-token-refresh pepsi-keydisc pepsi-crypto \
         pepsi-whitelist pepsi-wallets; do deluser "$u"; done
for g in pepsi-maildir pepsi-forward pepsi-token pepsi-admin \
         pepsi-telemetry; do delgroup "$g"; done

Die gleichnamigen Datenbankrollen können danach mit dropuser entfernt werden. Entfernen Sie pepsi-telemetry und pepsi-httpd-admin auf dieselbe Weise, falls sie installiert sind.

Installation aus den Quellen. Halten Sie pepsi.target an und deaktivieren Sie es, und führen Sie dann make uninstall mit demselben PREFIX/DESTDIR aus, mit dem Sie installiert haben. Es entfernt die Programme, die mitgelieferten Daten und die systemd-Units, nicht aber Konfiguration, Schlüssel oder Datenbank; entfernen Sie diese wie oben.

Warnung

Alles, was auf diese Weise entfernt wird, ist endgültig weg, einschließlich des Schlüsselverschlüsselungsschlüssels, ohne den sich die gespeicherten privaten Schlüssel nicht öffnen lassen. Legen Sie zuerst eine Sicherung an (Sicherung und Wiederherstellung), falls Sie die Schlüssel, die Mailinglisten oder ihr Archiv möglicherweise noch einmal brauchen.