Zum Inhalt

1:1-Spiegel aus dem Repo

Quelle: zulieferung/incidents/W6_INCIDENT_20260806_HETZNER_REBOOT_ODOO18.md · Stand der Quelldatei: 06.08.2026 23:06 · erzeugt: 14.08.2026 00:33 Diese Seite ist eine wortgetreue Kopie. Geaendert wird immer die Quelldatei, nie diese Seite.

INCIDENT 2026-08-06 — Hetzner-Reboot startet Odoo 18 statt 19 (Port-Uebernahme)
Status ZU (06.08.2026 ~23:05)
Aufgetreten 06.08.2026 22:15 (Hetzner-Wartung dedi8863, Kernel-Reboot 22:15–22:16)
Entdeckt 06.08.2026 ~22:40 durch M ("Odoo faehrt nicht hoch")
Dauer der Stoerung ~37 Minuten (22:15–22:52)
System Managed Server dedi8863.your-server.de · Odoo 19 Prod odoo_database_main19
Bearbeitet M (SSH/Termius) + G (Fernanalyse/Anleitung)

Ursachenkette

  1. Hetzner-Kernel-Reboot 22:15 -> Odoo 19 faehrt sauber herunter (odoo19.log: "Multiprocess clean stop"; letzte Zeile: DNS schon weg).
  2. Ms @reboot-Cron (aus v18-Zeit) startet nach dem Boot start_odoo.sh -> Odoo 18 (12 Prozesse, odoo18.conf).
  3. Beide Configs nutzen http_port 8069 -> die 18er besetzt den Port und bedient die Live-Domain mit der ALTEN DB odoo_database_main (jjr7).
  4. Odoo 19 hat KEINEN Autostart (start_odoo19.sh existiert seit 20.07., aber kein @reboot) -> bleibt unten.
  5. Erster 19er-Startversuch (22:50) stirbt an "Address already in use" (18er hielt den Port).

Erkennungs-Signatur (fuers naechste Mal)

  • API liefert Website-HTML statt JSON auf /json/2/* -> eine Odoo-Version OHNE diese Routen (v18) haelt den Port = falsche Version antwortet.
  • Agenten-Laeufe enden E3:icp_unreadable (Guard fail-closed) statt Verbindungsfehler — Server antwortet ja, nur falsch.
  • ps aux | grep odoo zeigt 18.0-Pfade statt 19.0.

Behebung (Reihenfolge, alle Befehle im Chat-Protokoll)

  1. Diagnose read-only: uptime, ps, crontab, Log-mtimes, conf-grep (Port-Kollision + DB-Trennung belegt).
  2. stop_odoo.sh (18er via pidfile) + kill 1782 2416 fuer zwei Nachzuegler.
  3. start_odoo19.sh -> Worker + queue-jobrunner "ready for db odoo_database_main19".
  4. Aussenpruefung G (W6-G-READ exec 7933): JSON-Antworten zurueck.
  5. Agenten-Selbstheilung belegt: eia-Laeufe 122–124 error E3:icp_unreadable (waehrend Stoerung, fail-closed, KEINE Writes) -> run 125 (23:03) GRUEN.
  6. @reboot-Cron ersetzt (Panel setzt "@reboot /bin/bash " selbst voran — Command-Feld beginnt mit -lc): DB-Warteschleife auf lvbp.your-database.de + start_odoo19.sh, Lock odoo19_start.lock. Alte 18er-Zeile entfernt. Gegenprobe crontab -l ok.
  7. Vorab-Ack fail_streak:eia:2026-08-06 im Audit (gov_actions), damit der WD den erklaerten Infrastruktur-Fehler nicht als Agent-Defekt eskaliert (Auto-Disable waere Fehlreaktion gewesen).

Nacharbeiten

  • [ ] queue_job e9da54ba… (beim Reboot "marked failed") im Job-Monitor nachfassen/requeue (M oder G-READ).
  • [ ] odoo18.log (8,7 GB!) rotieren/archivieren; odoo18-Restbetrieb klaeren (18er kuenftig nur noch manuell starten — wozu noch noetig?).
  • [ ] Incident in den Core uebernehmen (T5, INCIDENTS-Register) — Vorlage: diese Datei.
  • [ ] Monitoring-Idee: G-READ-Ping koennte kuenftig HTML-statt-JSON erkennen (BMA/WD-Ausbaustufe).

Lessons

  1. Parallel-Versionen mit gleichem Port + Autostart der alten Version = tickende Uhr. Nach jeder Migration den @reboot-Weg mit umziehen.
  2. Der Guard-fail-closed-Pfad hat exakt wie designed geschuetzt: kein Write, klare E3-Signatur, Selbstheilung ohne Zutun.
  3. "Server antwortet" heisst nicht "richtiger Dienst antwortet" — die HTML-Signatur ist der schnellste Fern-Indikator.
  4. Panel-Crons: Praefix beachten ("@reboot /bin/bash " wird vorangestellt) — Soll-Bild immer per crontab -l gegenpruefen.