In den frühen Morgenstunden im Rahmen automatischer System-Updates hat sich die Datenbank neu gestartet. Dadurch konnten die Mastodon-Dienste nicht mehr starten und die Instanz war vorübergehend offline. Es handelt sich wahrscheinlich um ein unglückliches Zusammenspiel automatischer Updates. Wir passen die Konfiguration jetzt so an, dass das künftig möglichst nicht noch einmal passiert.

Update mit Post Mortem

Datum des Vorfalls: 24.07.2026, 06:34 - 07:48 Uhr (CEST)
Schweregrad: Vollständiger Ausfall der Web-Oberfläche und API (Timeline/Login/Posting nicht erreichbar); Federation und Hintergrundverarbeitung liefen im Hintergrund weiter
Status: Behoben, Root Cause identifiziert, strukturelle Fixes umgesetzt

Zusammenfassung

Am 24.07.2026 in den frühen Morgenstundne installierte ‘unattended-upgrades’ routinemäßig Sicherheitsupdates für den Linux Server, darunter Kerberos-Bibliotheken (libkrb5, libgssapi-krb5). Das dabei automatisch mitlaufende Ubuntu-Standard-Tool ‘needrestart’ startete daraufhin unter anderem PostgreSQL und den Mastodon-Webserver in einem Rutsch und parallel neu. Der mastodon-web Service bzw. der zugehörige Puma Webserver scheiterte dann aber mehrfach an der Datenbankverbindung und wurde von systemd’s Crash-Loop-Schutz dauerhaft stillgelegt. Der Dienst blieb ca. 70 Minuten down, bis er manuell neu gestartet wurde.

Timeline

  • 06:34:29 - unattended-upgrades startet, installiert Updates für libgssapi-krb5-2, libkrb5-3, libk5crypto3, ibkrb5support0
  • 06:34:33 - needrestart stößt Batch-Neustart an: mastodon-sidekiq-*, mastodon-web, postgresql, …
  • 06:34:33 - PostgreSQL wird gestoppt
  • 06:34:36-44 - mastodon-web versucht 5× zu starten, scheitert jedes Mal mit ActiveRecord::DatabaseConnectionError
  • 06:34:44 - systemd: „Start request repeated too quickly” => Dienst wird als failed markiert, kein weiterer automatischer Neustartversuch
  • 06:34:50 - PostgreSQL ist wieder gestartet und funktionsfähig
  • 06:34 - 07:48 - mastodon-web bleibt inaktiv => Website nicht erreichbar. Sidekiq/Streaming laufen weiter, Federation und Hintergrundjobs werden weiter verarbeitet
  • 06:38 - Niklas bemerkt den Ausfall, informiert das restliche Team
  • 07:44 - Michael und Oliver starten die Fehlersuche
  • 07:48 - Manueller Neustart von mastodon-web und mastodon-streaming durch uns, Betrieb wieder normal

Root Cause

Damit ein erfolgreiches, reguläres Update zu diesem Ausfall führen konnte, mussten mehrere Dinge zusammenkommen:

  1. needrestart startet PostgreSQL und den Mastodon-Webserve gleichzeitig neu
  2. Der PostgreSQL-Neustart dauerte länger als das Retry-Zeitfenster für den Mastodon-Webserver
  3. Fehlende Reihenfolge für die Dienste: Die systemd-Unit von mastodon-web enthielt keine direkte Abhängigkeit zu PostgreSQL oder Redis. Wenn beide Dienste im selben Vorgang neugestartet werden, garantiert systemd ohne explizite After=/Wants=-Direktive keine Reihenfolge.
  4. Crash-Loop-Schutz von systemd: Puma scheitert beim Starten hart (Prozessende, kein Retry-Loop) wenn die erste DB-Verbindung fehlschlägt. systemd versucht das dann noch einige Male, nach 5 Fehlversuchen innerhalb von 10 Sekunden (systemd-Standardwert StartLimitBurst=5 / StartLimitIntervalSec=10s) ist dann aber Schluss.

Auswirkungen

  • Web-Oberfläche, Login und API: nicht erreichbar, 06:34 - 07:48 Uhr (74 Minuten)
  • Federation/Sidekiq-Verarbeitung (eingehende/ausgehende Aktivitäten, Push/Pull): weiterhin aktiv, keine Datenverluste

Maßnahmen

  1. Sofortmaßnahme: manueller Neustart von mastodon-web und mastodon-streaming
  2. Root-Cause-Analyse via journalctl, dpkg/unattended-upgrades-Logs etc
  3. Strukturelle Fixes in den systemd-Units von mastodon-web, allen Sidekiq-Queue-Diensten sowie mastodon-streaming:
    • After=postgresql@17-main.service redis-server.service
    • Wants=postgresql@17-main.service redis-server.service
    • StartLimitIntervalSec=60 / StartLimitBurst=10 (statt systemd-Standard 10s/5) als zusätzliches Sicherheitsnetz gegen kurze DB-Unterbrechungen

Lessons Learned

  • Automatisierte Sicherheitsupdates sind wichtig und sollen aktiv bleiben. Das Problem lag nicht in der Update-Installation selbst, sondern in nicht deklarierten Abhängigkeiten
  • systemd’s Crash-Loop-Schutz kann dazu führen, dass ein an sich transientes, kurzfristiges Problem zu einem längeren Ausfall führt, wenn die Restart-Limits zu eng gesetzt sind

Aktualisiert: