dev: Git-Deploy — FPM-Reload ohne Passwort getestet, PK_FPM_RELOAD ungesetzt lassen; Nginx-Fehlerlog ausgewertet, process_control_timeout bewusst nicht gesetzt

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dev/betrieb/git-deploy.md

@@ -61,6 +61,15 @@ Git-Checkout, und ausgeliefert wird ein Tag aus `origin`.
    Geht das nicht, beim Deploy `PK_FPM_RELOAD=` setzen. Das Skript wartet dann,
    bis FPM in Ploi neu geladen ist.
 
+   **Getestet 06.10.2026: funktioniert.** Kein Passwort nötig (Ploi erlaubt dem
+   Benutzer `ploi` genau diesen Befehl), Exit-Code 0, keine Ausgabe. Prüfen lässt
+   es sich mit `ps -o pid,lstart,args -C php-fpm8.4` vorher und nachher: der
+   `master process` behält PID und Startzeit, die `pool www`-Prozesse sind neu.
+   **`PK_FPM_RELOAD` deshalb nicht setzen** und FPM nicht zusätzlich in Ploi
+   über „Restart“ neu starten — ein Restart entfernt kurz den Socket, Nginx
+   meldet dann `connect() to unix:/run/php/php8.4-fpm.sock failed` und liefert
+   502 (so beim Deploy von `v1.3.0`, 16:51).
+
 ## B — Einmalig: Live-Verzeichnis in einen Checkout umwandeln
 
 Live läuft auf `v1.1.0`. Das Verzeichnis wird an Ort und Stelle zum Checkout
@@ -204,6 +213,28 @@ Was bei der Umwandlung (B) auftrat, für den Fall, dass ein weiterer Server so u
 Aufräumen nach ein paar stabilen Tagen: `~/deploy-v1.1.0.tgz`,
 `~/backup-vor-v1.1.0.tgz`, `~/backup-vor-git.tgz`, `~/vor-git/`.
 
+## Betrieb: PHP-FPM beim Deploy
+
+Jeder Reload bricht Anfragen ab, die in dieser Sekunde laufen. Im Nginx-Fehlerlog
+(`/var/log/nginx/pressekonto.com-error.log`, für `ploi` lesbar) erscheinen dann
+einzelne `recv() failed (104: Connection reset by peer)`, am 06.10. genau zu den
+Deploys von `v1.1.3` (15:37, 1×) und `v1.2.0` (16:06, 6×). Das sind kurze 502er,
+fast nur für Bots, kein Absturz.
+
+Abhilfe wäre `process_control_timeout = 10s`: Die alten Worker dürfen laufende
+Anfragen noch zu Ende bringen. Die Einstellung gehört in den Abschnitt `[global]`
+von `/etc/php/8.4/fpm/php-fpm.conf` (root). Ploi bietet nur „Edit FPM ini“
+(`php.ini`, dort wirkungslos), „Edit CLI ini“ und „Edit pool“ (`www.conf`).
+**Nie in die Pool-Datei eintragen** — dort ist der Schlüssel unbekannt, FPM
+startet beim nächsten Reload nicht mehr und die Seite ist offline.
+**Entscheidung 06.10.2026: nicht gesetzt.** Bei Bedarf über den Ploi-Support
+oder mit root-Zugang, danach `php-fpm8.4 -t` und erst dann neu laden.
+
+Übrige Einträge im Nginx-Fehlerlog sind unbedenklich: `access forbidden by rule`
+(Ploi sperrt Punktdateien, Scanner suchen `/.env` u. Ä.) und `directory index of
+…/public/api/ is forbidden` (dort liegt die API-Spezifikation `v1.yml`, ein Aufruf
+von genau `/api/` bekommt 403). Ein Zugriffsprotokoll für die Site führt Ploi nicht.
+
 ## Später: Changelog
 
 Der Changelog-Entwurf
@@ -223,3 +254,4 @@ Ausfall des Anbieters keinen Deploy abbricht.
 | 06.10.2026 | Umwandlung Live (A, B) | Server-Zugang zu Forgejo per Deploy-Key (nur lesen). Git 2.43. Befunde siehe F: fehlende `.gitignore`, Altdatei Fortify, Flux-Icons nicht im Repository. |
 | 06.10.2026 | `v1.1.3` | `.gitignore`-Muster `Icon` korrigiert, vier Icons versioniert. Erster Git-Deploy `v1.1.0` → `v1.1.3`: keine Migration, Composer „Nothing to install", Caches, Worker, FPM ohne Fehler, Version `v1.1.3`. Danach alte Build-Dateien entfernt. `v1.1.1` und `v1.1.2` waren nie einzeln live. |
 | 06.10.2026 | `v1.2.0` | Volt entfernt (Livewire-4-Single-File-Components). Erster Deploy, der nur noch `deploy.sh` brauchte: keine Migration, Composer entfernt `livewire/volt`. Vom Betreiber durchgeklickt (Login, Kundenbereich, Admin), unauffällig. |
+| 06.10.2026 | FPM und Nginx-Fehlerlog | `sudo -S service php8.4-fpm reload` ohne Passwort bestätigt (Master bleibt, Worker neu) — `deploy.sh` lädt FPM künftig selbst, `PK_FPM_RELOAD` bleibt ungesetzt. Nginx-Fehlerlog ausgewertet: Verbindungsabbrüche nur zu den Deploy-Zeitpunkten, `process_control_timeout` bewusst nicht gesetzt (siehe „Betrieb: PHP-FPM beim Deploy“). |