1:1-Spiegel aus dem Repo
Quelle: planning/PROJEKT_STAGING_HETZNER_TEST_PATCHES_REMOVE.md · Stand der Quelldatei: 13.08.2026 23:15 · erzeugt: 14.08.2026 00:33
Diese Seite ist eine wortgetreue Kopie. Geaendert wird immer die Quelldatei, nie diese Seite.
PROJEKTBLATT · STAGING-HETZNER-TEST-PATCHES-REMOVE¶
[W6-ODOO · GOV]
▮ W6-ODOO · GOVERNOR · Projektanlage
Angelegt 13.08.2026 · Codename von M · Status: GEPLANT, nicht gestartet
Ziel in einem Satz: Auf dem Staging-Server belegen, ob die vier Server-Patches aus patches_to_server heute noch gebraucht werden — und ob der Restart-Loop der Warteschlange dort reproduzierbar ist.
1 · Warum es dieses Projekt gibt¶
Drei Befunde von heute laufen hier zusammen:
patches_to_serverersetzt vier Kernfunktionen des Odoo-Servers (Cron-Thread, Cron-Arbeiter-Start, Bus-Schleife, Bus-Hooks). Begründung laut Manifest: „no postgres maintenance DB".- Hetzner widerspricht dieser Begründung (Ticket 2025101703028637, 21.10.2025): Zugriff auf
postgresist für jeden DB-User möglich — über den UNIX-Socket, nicht über TCP. queue_job_lockist leer, deshalb requeued der Job-Runner jeden Job, der länger als 10 Sekunden läuft — die belegte Ursache des nächtlichen Restart-Loops.
Wenn (2) zutrifft, ist die riskanteste Modifikation der Instanz möglicherweise überflüssig. Und (3) ist unabhängig davon zu klären, aber am selben Ort mit demselben Aufwand.
Kein einziger Schritt dieses Projekts berührt die Produktion.
2 · Ergebnisse, die am Ende vorliegen sollen¶
| # | Ergebnis | Form |
|---|---|---|
| E1 | Der Ist-Zustand der odoo.conf ist dokumentiert: db_host, hetzner, channels (in welcher Sektion?), limit_time_*, Startzeile |
Datei im Register |
| E2 | Belegt: Erreicht Odoo postgres über den UNIX-Socket? |
Protokoll einer psql-Probe |
| E3 | Belegt: Laufen Zeitpläne und Bus ohne die Umleitung (Schalter hetzner aus)? |
Herzschlag-Messung über 48 h |
| E4 | Belegt: Entstehen auf Staging Sperrzeilen in queue_job_lock, während ein Job läuft? |
Abfrage während eines Langläufers |
| E5 | Belegt: Behebt channels in eigener [queue_job]-Sektion die Kapazität C:1 → C:8? |
Logzeile nach Neustart |
| E6 | Empfehlung an Sandas — mit Belegen, nicht mit Vermutungen | Bericht |
3 · Stufen, jede einzeln nachweisbar und umkehrbar¶
Grundregel: immer nur eine Sache auf einmal ändern.
| Stufe | Handlung | Nachweis | Rückweg |
|---|---|---|---|
| S0 | Nur lesen. odoo.conf sichern, psql-Probe über Socket auf postgres, queue_job_lock während eines laufenden Jobs abfragen |
E1, E2, E4 | keiner nötig |
| S1 | db_host leeren (oder auf Socket-Verzeichnis setzen), Neustart |
Verbindung steht über Socket, postgres erreichbar |
alten Wert zurück |
| S2 | Schalter hetzner aus — die vier Patches verhalten sich damit wie Odoo-Standard, ohne Deinstallation |
E3: Test-Cron feuert, Bus lebt, 48 h ruhig | Schalter zurück |
| S3 | channels in eine eigene [queue_job]-Sektion, Neustart |
E5: Log zeigt root(C:8,…) |
Zeile zurück |
| S4 | Erst wenn S2 zwei Tage sauber läuft: -u patches_to_server aus der Startzeile |
Startzeit sinkt, alles läuft weiter | Startzeile zurück |
Der billigste Test ist S2. Der Schalter hetzner ist die eingebaute Rückfallebene der Patches — eine Zeile in der Konfiguration, sofort umkehrbar, ohne dass ein Modul deinstalliert oder gelöscht wird (Grundsatz R1).
4 · Der Präzisionspunkt, der über den ganzen Test entscheidet¶
Hetzner empfiehlt „localhost als DB-Host eintragen". Das ist ungenau, und der Unterschied ist der ganze Test:
db_host |
was psycopg2 tatsächlich tut |
|---|---|
localhost |
TCP auf 127.0.0.1 — genau der Weg, der für postgres nicht funktioniert |
| leer / nicht gesetzt | UNIX-Socket im Standardverzeichnis |
/var/run/postgresql |
UNIX-Socket, ausdrücklich benannt |
Der Socket muss nicht angelegt werden — PostgreSQL erzeugt ihn selbst (unix_socket_directories). Zu prüfen ist nur, ob er existiert und für den Odoo-Benutzer lesbar ist.
Steht heute db_host = localhost in der Konfiguration, wäre das die einfachste denkbare Erklärung dafür, dass es die Patches überhaupt gibt. Das ist die erste Zeile, die S0 liefert.
5 · Voraussetzungen, die vor S0 geklärt sein müssen¶
| # | Frage | Warum |
|---|---|---|
| V1 | Ist der Staging-Odoo eine Kopie der Produktionsdatenbank oder leer? | Ohne echte Datenmenge verhält sich die Warteschlange anders; ein Export über 250 Varianten braucht Daten |
| V2 | Laufen dort dieselben Modulstände? | Der Vergleich taugt nur bei identischen Versionen — VERSIONEN.md aus dem Modul-Register ist die Vorlage |
| V3 | Ist der Shopify-Anschluss abgeklemmt? | Der einzige Punkt, an dem ein Staging-Test echten Schaden anrichten kann: sonst exportiert der Test in die echten Shops |
| V4 | Wer hat Serverzugang, und über welchen Weg arbeite ich? | siehe § 6 |
| V5 | Gibt es ein Zeitfenster, in dem Neustarts unproblematisch sind? | S1–S4 brauchen je einen Neustart |
V3 ist die einzige echte Gefahrenstelle des Projekts. Wird sie nicht geklärt, wird nicht gestartet.
6 · Zugangsweg — Empfehlung¶
Weg A · Werkbank-Terminal auf Ms Mac. Claude Code dort, SSH über Ms eigenen Schlüssel im ssh-agent. Ich schreibe Befehlspakete, die Werkbank führt aus und liefert Roh-Ausgaben, ich werte aus. Kein Schlüssel bei mir, jeder Befehl vorher sichtbar. Das ist das Hausmuster Leitstand/Werkbank.
Weg B · Auditierter n8n-Kanal (später, für wiederkehrende Lesungen): eigener Systembenutzer auf Staging mit minimalen Rechten, Zugangsdaten im n8n-Credential-Store, harte Allowlist erlaubter Befehle, Board-Pflicht wie bei jedem Agenten. Nur Staging, niemals Produktion.
Weg C · SSH direkt aus dem Governor-Fenster: abgeraten. Die Sandbox erreicht den Server vermutlich gar nicht, und ein privater Schlüssel bei mir verstößt gegen die Hausregel „Zugangsdaten nur im Credential-Store". Nicht ausprobiert — das wäre ohne Freigabe ein Zugriffsversuch auf fremde Infrastruktur.
7 · Ablauf und Aufwand¶
| Schritt | Wer | Dauer |
|---|---|---|
| V1–V5 klären | M / Sandas | — |
| Kickoff-Paket „T-STAGING-S0" schreiben | Governor | 1 h |
| S0 ausführen, Roh-Ausgaben liefern | Werkbank | 30 min |
| S0 auswerten, S1/S2 entscheiden | Governor → M | 1 h |
| S1 + S2 | Werkbank | 1 h + 48 h Beobachtung |
| S3 (Kapazität) | Werkbank | 30 min |
| S4 nur bei Erfolg von S2 | Werkbank | 30 min |
| Bericht E6 an Sandas | Governor | 2 h |
Gesamt: rund einen Arbeitstag verteilt über drei bis vier Tage — der Rest ist Beobachtungszeit.
8 · Risiken¶
| Risiko | Bewertung | Gegenmittel |
|---|---|---|
| Staging exportiert versehentlich in echte Shops | hoch, wenn V3 ungeklärt | V3 vor S0 klären, sonst Abbruch |
| Nach S2 laufen Zeitpläne auf Staging nicht mehr | mittel | genau das ist der Testinhalt; Schalter zurück, eine Zeile |
| Staging weicht so stark von Produktion ab, dass das Ergebnis nichts aussagt | mittel | V1/V2 vorher belegen, sonst ist der Test wertlos |
| Erkenntnis wird auf Produktion übertragen, bevor sie belastbar ist | hoch | Übertragung ist ein eigener Entscheid mit Kennungszeile und nicht Teil dieses Projekts |
9 · Abgrenzung — was dieses Projekt NICHT tut¶
- Keine Änderung an der Produktion. Kein einziger Schritt.
- Keine Deinstallation von
patches_to_server, auch nicht auf Staging. Der Schalter genügt (R1: niemals löschen). - Keine Bewertung, ob Sandas gut oder schlecht gearbeitet hat. Das Projekt liefert Messwerte, keine Urteile.
- Keine Übertragung der Ergebnisse auf Produktion — das ist ein Folgeprojekt mit eigener Freigabe.
10 · Nächster Zug¶
Der Governor wartet. Zu tun ist zuerst V1–V5. Sobald diese fünf Fragen beantwortet sind, schreibe ich das Kickoff-Paket „T-STAGING-S0" — reine Lesung, kein Neustart, keine Änderung.