From 936b0837bf31ba7f4cebc0c00d5c14f15d914fc1 Mon Sep 17 00:00:00 2001 From: Hitonabi Date: Sun, 26 Jul 2026 17:23:14 +0200 Subject: [PATCH] docs(savepoint): Uhrzeit-Meldung erledigt - mit dem Beweis, der zaehlt Die "Substantial drift 7200 seconds"-Meldung kam nicht alle paar Sekunden, sondern einmal pro Absender-Hostname (celery memoized nach hostname) - und der Container-Hostname wechselt bei jedem Neubau. Die vier Meldungen im Log sind genau vier Deploys. Der Beweis, dass sie weg ist: Um 14:57:33 synchronisierte sich der Worker mit celery@d160eb2f3afd, dem frischen Container nach dem Deploy. Ein NEUER Hostname umgeht die Merk-Sperre, die Warnung haette also feuern muessen. Sie kam nicht. Dazu gemessen: TZ=UTC wirkt auf Windows wirklich (time.timezone -3600 -> 0), und die celery-Zeitstempel im lokalen Worker-Log stehen in UTC. Ausserdem festgehalten: Der Windows-Worker laeuft auf gemischten Dateistaenden (tasks.py 13:19, ripping.py 14:06, zombies.py 14:17) - die Sprachwahl ist vollstaendig drin, meta_merken fehlt noch. Es fehlt eine Versionsanzeige, die so etwas sichtbar macht, statt es nur beim Nachsehen auf dem PC zu finden. Co-Authored-By: Claude Opus 5 --- SAVEPOINT.md | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 71 insertions(+), 1 deletion(-) diff --git a/SAVEPOINT.md b/SAVEPOINT.md index 4f2c43d..009ca33 100644 --- a/SAVEPOINT.md +++ b/SAVEPOINT.md @@ -126,7 +126,62 @@ RIPPY_REPO_URL= \ RIPPY_ENV_SRC=/home/arcane/projects/rippy/.env ./deploy.sh ``` -### 4. Was noch offen ist +### 4. Die Uhrzeit-Meldung: nachgemessen statt gehofft + +Zwei offene Fragen zur `Substantial drift … 7200 seconds`-Meldung, beide jetzt +beantwortet. + +**Wirkt `set TZ=UTC` auf Windows überhaupt?** Das war ungeprüft — und die +MSVC-Dokumentation verlangt eigentlich die Form `UTC0`. Hier gemessen: + +| | `time.timezone` | `time.altzone` | `isdst` | +|---|---|---|---| +| ohne `TZ` | −3600 | −7200 | 1 | +| `TZ=UTC` | **0** | −3600 | **0** | +| `TZ=UTC0` | 0 | −3600 | 0 | + +Celerys `utcoffset()` rechnet `time.timezone // 3600` (bzw. `altzone`, wenn +`isdst`) — mit `TZ=UTC` also 0, genau wie in den Containern. `TZ=UTC` genügt, +`UTC0` bringt nichts zusätzlich. + +**Warum kam die Meldung „immer wieder"?** Sie kam nicht alle paar Sekunden, +sondern **einmal pro Absender**: + +```python +@memoize(maxsize=1000, keyfun=lambda a, _: a[0]) +def _warn_drift(hostname, drift, local_received, timestamp): + # we use memoize here so the warning is only logged once per hostname +``` + +Der Absender ist der Linux-Container, und dessen Hostname wechselt bei **jedem +Neubau**. Die Meldungen im Log (`7e71250606aa`, `09d001df95a4`, `7c2c179a1953`, +`3a9f4808ed51`) sind genau vier Deploys — deshalb kam sie „immer wieder", ohne +zwischendurch zu nerven. + +**ERLEDIGT, und zwar sauber bewiesen.** Aus dem lokalen Worker-Log auf dem +PC (`%LOCALAPPDATA%\Rippy Worker\worker.log`): + +``` +[2026-07-26 14:21:17,301: INFO/MainProcess] tobisnicerpc@TobisNicerPC ready. +[2026-07-26 14:23:17,318: WARNING/MainProcess] Zombie-Erkennung: {...} +[2026-07-26 14:57:33,460: INFO/MainProcess] sync with celery@d160eb2f3afd +``` + +Zwei Dinge stehen da: + +1. Die Zeitstempel sind **UTC** (14:21, während es auf dem PC 16:21 war) — + `TZ=UTC` ist im laufenden Worker also wirklich aktiv. +2. Um 14:57:33 kam ein **neuer** Absender-Hostname dazu (der Container von + heute Abend). Genau dafür ist die Merk-Sperre blind — die Warnung hätte + feuern MÜSSEN. Sie kam nicht. + +Nebenbei ist damit auch die Log-Brücke bestätigt: Die Zeilen von 14:21 und +14:23 stehen als `w:tobisnicerpc` in Rippys Log. (Ich hatte sie zuerst +übersehen, weil `/logs` neueste-zuerst liefert und ich `tail` statt `head` +gefiltert hatte — die Liste war nicht leer, ich habe an der falschen Seite +geschaut.) + +### 5. Was noch offen ist - **Voller Durchlauf läuft gerade** (Job `bfb7a946`, über den neuen `retry-rip`-Weg gestartet): Akira-BD → Auswurf → Kompression auf @@ -141,6 +196,21 @@ RIPPY_ENV_SRC=/home/arcane/projects/rippy/.env ./deploy.sh - **`sudo ./install.sh` auf einem FRISCHEN Host ist weiter unbelegt.** Der Prüfpfad (`--nur-pruefen`) läuft auf der VM sauber durch, alle fünf Prüfungen grün. Ein echter Root-Lauf hier hätte den laufenden Rip getötet. +- **Der Windows-Worker läuft auf gemischten Dateiständen** — direkt auf dem PC + nachgesehen (`C:\Program Files\Rippy Worker`): `tasks.py` 13:19, `ripping.py` + 14:06, `zombies.py` 14:17. Die Sprachwahl ist vollständig drin (geprüft: + `tasks.py` liest sie, `ripping.py` gibt sie an HandBrake), `meta_merken`/ + `RIP_FERTIG` von heute Abend fehlen noch. Für diesen Test unerheblich (die + Marke setzt der Linux-Worker bei der Übergabe), aber **nach dem Test einmal + den Installer laufen lassen**, damit alles auf einem Stand ist. +- **Es fehlt eine Versionsanzeige für den externen Worker.** Nichts vergleicht + seinen Code-Stand mit dem des Servers; „läuft auf gemischten Ständen" war nur + zu sehen, weil ich auf dem PC selbst nachgesehen habe. Ein Zähler in `caps.py` + (z. B. der Commit-Kurz-Hash) und eine Warnung im UI wären der saubere Weg — + bewusst nicht heute Nacht gebaut. +- **Im Wurzelverzeichnis der Freigabe liegt eine verwaiste + `Evangelion 2.22_t00.mkv`** ohne zugehörigen Job. Kann weg, wenn du sie nicht + brauchst — Rippy zeigt sie nirgends an, weil kein Eintrag darauf zeigt. ---