Der Betrieb der Instanz ist bei gleichbleibenden Kosten weiterhin für mindestens 18 Monate finanziell abgesichert.

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

Der Betrieb der Instanz ist bei gleichbleibenden Kosten weiterhin für mindestens 18 Monate finanziell abgesichert.

Der Betrieb der Instanz ist bei gleichbleibenden Kosten weiterhin für mindestens 18 Monate finanziell abgesichert.

Der Betrieb der Instanz ist bei gleichbleibenden Kosten weiterhin für mindestens 18 Monate finanziell abgesichert.

Der Betrieb der Instanz ist bei gleichbleibenden Kosten weiterhin für mindestens 18 Monate finanziell abgesichert.

Der Betrieb der Instanz ist bei gleichbleibenden Kosten weiterhin für mindestens 18 Monate finanziell abgesichert.

In einer außerordentlichen Mitgliederversammlung haben die Mitglieder eine Nachfolge gewählt. Oliver Jakobi übernimmt ab sofort die Rolle als Zweites Vorstandsmitglied und wird gemeinsam mit Niklas Barning die Geschäfte des Vereins führen. Damit bleibt die Handlungsfähigkeit des Vereins gesichert.

Wir suchen Verstärkung im Moderationsteam

Wir möchten unser Moderator:innen-Team vergrößern und suchen daher ab sofort eine Person, die: • einen Account auf dieser Instanz hat • schon länger im Fediverse aktiv ist • teamfähig ist • nicht impulsiv handelt • auch abends und am Wochenende per Messenger erreichbar ist • zuverlässig und kontinuierlich mitarbeiten kann

Dies ist keine Admin-Stelle. Du erhältst keinen Zugriff auf den Leuchtturm oder Server. Bewerbungen bitte direkt per Mail an moin@norden.social.

Der Betrieb der Instanz ist bei gleichbleibenden Kosten weiterhin für mindestens 18 Monate finanziell abgesichert.

Der April war vergleichsweise teuer weil da sowohl das Sponsoring des UX Camp Bremen 2025 als auch Mehrkosten bei Hetzner reinfallen. Letztere sind entstanden, weil wir dort auf kleinere Hardware umgezogen sind, was die Kosten mittelfristig senken sollte. Die Systeme mussten für den Umzug aber ein gutes Stück parallel laufen, weswegen wir einmalig spürbare Mehrkosten hatten.

Der Betrieb der Instanz ist bei gleichbleibenden Kosten weiterhin für mindestens 18 Monate finanziell abgesichert.