Wie der Cron-Watchdog das Node.js-Problem löst

Wer moderne Web-Anwendungen mit Node.js oder Next.js auf einem klassischen Shared-Hosting-Paket (wie All-Inkl oder Hetzner) betreiben möchte, stößt schnell auf ein hartnäckiges Phänomen: Die Anwendung läuft anfangs perfekt, doch nach wenigen Minuten ist die Webseite plötzlich offline.

In diesem Artikel werfen wir einen genauen Blick auf die Ursachen und erklären abstrakt und für jeden verständlich, wie eine ausgeklügelte Flip-Flop-Architektur in Kombination mit einem Cron-Watchdog dieses Problem ein für alle Mal löst.

1. Die Ausgangslage: WG-Zimmer vs. Einfamilienhaus

Um zu verstehen, warum Hoster so streng mit Hintergrundprozessen umgehen, hilft ein anschaulicher Vergleich aus der Alltagswelt:

  • Shared Hosting ist wie ein Zimmer in einer großen Wohngemeinschaft (WG)

    • Du teilst dir die Infrastruktur (Küche, Bad, Flur, Stromleitung) mit Hunderten anderen Mitbewohnern
    • Der Vermieter (Hoster) hat strenge Hausregeln aufgestellt, damit niemand den Flur mit Kisten blockiert oder ständig den gesamten Warmwasserspeicher leert
    • Wenn du ein ressourcenintensives Gerät dauerhaft laufen lässt, greift der Hausmeister ein und zieht den Stecker, um die anderen Mitbewohner zu schützen

  • Ein Virtual Private Server (VPS) ist wie ein eigenes Einfamilienhaus

    • Du hast das gesamte Gebäude und alle Leitungen exklusiv für dich allein
    • Du besitzt den Schlüssel zum Hauptsicherungskasten (Root-Rechte) und darfst in deinen vier Wänden machen, was du willst
    • Wenn deine Waschmaschine ausläuft oder die Stromleitung überlastet ist, betrifft das ausschließlich dein eigenes Haus

2. Das Kernproblem: PHP (Flüchtig) vs. Node.js (Permanent)

Der Hauptgrund, warum Node.js auf einem Shared-Hosting-Server beendet wird, während klassische WordPress– oder PHP-Seiten seit Jahrzehnten stabil laufen, liegt im grundlegend unterschiedlichen Architekturmodell der beiden Sprachen:

  • Das flüchtige Modell von PHP (Der Besucher-Klick)

    • Ein Besucher ruft deine Webseite im Browser auf
    • Der Webserver (Apache) bemerkt die Anfrage und weckt blitzschnell einen PHP-Prozess aus dem Tiefschlaf
    • Das PHP-Skript arbeitet für wenige Millisekunden, baut die fertige HTML-Seite zusammen und schickt sie zurück an den Besucher
    • Der entscheidende Punkt: Unmittelbar nach der Antwort beendet sich das PHP-Skript vollständig. Es belegt im Ruhezustand exakt 0 Bytes Arbeitsspeicher und verbraucht keinerlei CPU-Leistung

  • Das permanente Daemon-Modell von Node.js (Der Dauerläufer)

    • Im Gegensatz zu PHP bringt Node.js seinen eigenen, vollwertigen Webserver mit
    • Wenn du eine Node.js-App startest, reserviert sie dauerhaft Arbeitsspeicher für ihre JavaScript-Engine (V8) und öffnet einen festen Netzwerk-Port (z. B. 3004)
    • Die Anwendung muss 24 Stunden am Tag, 7 Tage die Woche permanent im Hintergrund aktiv bleiben, um auf eingehende Besucheranfragen zu horchen
    • Sobald der Node.js-Prozess stirbt oder vom Server gestoppt wird, ist deine gesamte Webseite sofort offline

3. Der 11-Minuten-Reaper des Hosters

Auf Shared-Hosting-Servern wacht ein automatisiertes Systemprogramm über die Stabilität und Ressourcenverteilung im Hintergrund.

  • Die Überwachung von Hintergrundprozessen
    • Sobald du deine Kommandozeile (SSH) schließt, sendet das Betriebssystem ein Signal, das verwaiste Hintergrundprozesse automatisch beendet (KillUserProcesses)
    • Selbst wenn du einen Prozessmanager wie PM2 nutzt, der den Prozess nach einem Abbruch sofort neu startet, lauern im Hintergrund automatisierte Kontrollprogramme des Hosters
  • Empirische Messdaten bei All-Inkl.com
    • Unsere kontinuierlichen Systemanalysen und Log-Auswertungen haben gezeigt, dass die Bereinigungsroutine des Hosters in einem festen Takt arbeitet
    • Exakt alle 11 bis 12 Minuten durchsucht der sogenannte Reaper den Arbeitsspeicher nach dauerhaften Nutzerprozessen und beendet diese rigoros per Zwangsabschaltung (SIGKILL)
    • Ein herkömmlich gestarteter Node.js-Prozess hat auf einem Shared-Server folglich eine maximale Lebenserwartung von knapp 12 Minuten

4. Die Gesamtarchitektur: Die 4 Säulen der Lösung

Um Node.js trotz dieser harten Systemrestriktionen dauerhaft und hochverfügbar zu betreiben, haben wir ein robustes, selbstheilendes System entwickelt. Es verzichtet auf rohe Gewalt und setzt stattdessen auf intelligentes Timing und strikte Aufgabenteilung.

[1. KAS-Cron-Impuls (jede Minute)] ─── HTTP ───> [2. cron_pm2.php (Watchdog)]
                                                       │
                                               Check per cURL auf Port 3004 & 3005
                                                       │
                                       ┌───────────────┴───────────────┐
                                       ▼                               ▼
                             [Mindestens 1 Port lebt]            [BEIDE PORTS TOT]
                                       │                               │
                                [Alles stabil ✓]               [3. PM2-Wiederbelebung]
                                                                  * Atomares Cleanup
                                                                  * Neustart orchestrator.js
                                                                  * Sofortiger Push-Alarm

Säule 1: Das proaktive Flip-Flop-System (Zwillings-Rotation)

Anstatt passiv zu warten, bis das Bereinigungsskript des Hosters unseren Prozess nach 11 Minuten beendet, ergreifen wir proaktiv die Initiative. Wir beenden unsere Prozesse selbst – jedoch erst, nachdem ein frischer Ersatz bereits im Hintergrund hochgefahren ist.

  • Das Zwillings-Prinzip
    • Im Hintergrund existieren zwei exakte Kopien deiner Anwendung: Instanz prod-A auf Port 3004 und Instanz prod-B auf Port 3005
  • Der 7,5-Minuten-Takt
    • Ein zentraler Steuerungsprozess (Orchestrator) startet alle 7 Minuten und 30 Sekunden die jeweils inaktive Zwillings-Instanz im Hintergrund
    • Da dieses Intervall deutlich unter der 11-Minuten-Grenze des Hosters liegt, greift der Reaper niemals ein
    • Unsere laufenden Prozesse sind für das Betriebssystem stets jünger als der kritische Schwellenwert und werden als völlig unbedenklich eingestuft
[prod-A (Port 3004) 🟢] ──(nach 7:30 Min.)──> startet [prod-B (Port 3005) ⏳]
                                                          │
                                                (Check HTTP 200 OK)
                                                          │
                                                          ▼
[prod-A sanft beendet ✓] <──(Apache routet um)── [Setze Flag-File B 🟢]

Säule 2: Zero Downtime & Graceful Drain

Eine Umschaltung im laufenden Betrieb birgt Risiken. Besucher könnten mitten im Klick eine Fehlermeldung erhalten oder laufende Downloads abbrechen. Unsere Architektur verhindert dies durch zwei Sicherheitsmechanismen:

  • Nahtlose Umschaltung ohne Ausfallzeit (Zero Downtime)
    • Wenn der Orchestrator die neue Instanz startet, leitet der Webserver die Besucher nicht blindlings um
    • Er wartet, bis die neue Instanz vollständig geladen ist und auf eine interne Testanfrage mit dem Statuscode HTTP 200 OK antwortet
    • Erst nach diesem erfolgreichen Gesundheits-Check setzt das System eine winzige Markierungsdatei (Flag-File). Der Webserver registriert diese Datei im Bruchteil einer Sekunde und leitet alle neuen Besucher auf den frischen Port um. Niemand bemerkt den Wechsel im Hintergrund
  • Sanftes Ausklingen laufender Verbindungen (Graceful Drain)
    • Was passiert mit Besuchern, die auf der alten Instanz gerade einen längeren Text lesen oder eine Datei herunterladen?
    • Die alte Zwillings-Instanz wird nicht abrupt vom Strom getrennt, sondern erhält ein sanftes Abschaltsignal (SIGTERM)
    • Sie nimmt ab sofort keine neuen Besucher mehr an, lässt aber alle bereits bestehenden Verbindungen und Datenströme bis zu 30 Sekunden lang in Ruhe zu Ende laufen, bevor sie sich endgültig schließt

Säule 3: Der PHP-Watchdog als Notfall-Defibrillator

Was geschieht, wenn der Hoster bei einer unangekündigten nächtlichen Serverwartung nicht nur unsere Node-Prozesse, sondern den gesamten PM2-Dienst mitsamt dem Orchestrator aus dem Speicher löscht? Für dieses Szenario existiert eine absolut verlässliche Rückfallebene.

  • Der minütliche Herzschlag-Check
    • Über das Kundenadministrationssystem (KAS) von All-Inkl ist ein automatischer Zeitplaner (Cronjob) eingerichtet
    • Jede Minute ruft dieser Cronjob das extrem schlanke PHP-Skript cron_pm2.php auf
    • Das Skript prüft über eine lokale HTTP-Anfrage ressourcenschonend und innerhalb weniger Millisekunden, ob einer der beiden Zwillings-Ports antwortet
  • Die vollautomatische Wiederbelebung
    • Solange mindestens eine Instanz einwandfrei antwortet, beendet sich der Wächter stillschweigend
    • Nur wenn beide Ports gleichzeitig tot sind, erkennt der Watchdog den absoluten Notfall
    • Er löscht sämtliche hängengebliebenen Prozessleichen, setzt alle Statusdateien zurück und startet den Orchestrator von Grund auf neu. Selbst nach einem totalen Server-Crash ist die Webseite nach spätestens 60 Sekunden wieder online

Säule 4: Echtzeit-Push & iOS Kurzbefehle (‚Siri, Server prüfen‘)

Um die Serverstabilität zu überwachen, möchte man sich nicht mehrmals täglich via SSH einloggen oder endlose Logdateien durchsuchen. Unser entkoppeltes Benachrichtigungssystem (notifier.php) sorgt für vollständige Transparenz direkt auf dem Smartphone:

  • Echtzeit-Alarmierung bei Notfällen
    • Fällt das System aus und der Watchdog muss eingreifen, schickt der Notifier parallel zur klassischen Warn-E-Mail sofort eine Push-Benachrichtigung auf dein iPhone 🚨
    • Wir verwenden dafür den hochverfügbaren, kostenlosen Service von ntfy.sh. Da dieser Dienst extern in der Cloud läuft, kann er vom Hoster nicht blockiert oder beendet werden
  • Der tägliche Statusbericht am Abend
    • Jeden Abend um 23:50 Uhr sendet das System vollautomatisch einen kompakten Tagesbericht auf den Sperrbildschirm
    • Du siehst auf einen Blick die exakte Verfügbarkeitsquote (z. B. Stabilität: 99.93 % bei 1440 minütlichen Checks) sowie den aktuellen Status der Prozess-Zwillinge
  • Sichere On-Demand Abfrage per iOS Kurzbefehl
    • Über die Kurzbefehle-App unter iOS lässt sich eine Sprachsteuerung einrichten (‚Siri, Server prüfen‘), die eine geheime URL auf deinem Server aufruft (?key=Geheim&mode=hook_logs)
    • Sicherheitskonzept Zero Data Leakage: Wenn jemand deine Webhook-URL herausfindet und sie im Browser öffnet, zeigt die Webseite ausschließlich einen unbedenklichen Statusstring an (Status: OK). Sensible Systemdaten, Prozesslisten oder interne Fehlermeldungen werden niemals im Browserfenster ausgegeben, sondern exklusiv und verschlüsselt per Push auf den Bildschirm deines iPhones übertragen

5. Fazit & Technische Umsetzung

Mit dem Zusammenspiel aus proaktiver Flip-Flop-Rotation, nahtloser Umschaltung per .htaccess und dem minütlichen PHP-Watchdog lässt sich Next.js oder Node.js absolut stabil, ressourcenschonend und zu 100 % ausfallsicher auf einem Shared-Hosting-Paket betreiben. Das System erfüllt alle Vorgaben des Hosters und schützt sich selbst vor Zwangsbeendigungen.

Für Systemarchitekten, DevOps-Engineers und Entwickler, die diese Architektur im Detail nachvollziehen oder auf ihrem eigenen Server installieren möchten, stellen wir die vollständige Dokumentation sowie alle Quellcodes frei zur Verfügung: