fix: php-fpmをexec php-fpm -Fで起動しCrashLoopBackOff(9000二重bind)/502を修正

setupシェルの子として起動していたためコンテナ再起動時にシェル(PID1)がSIGTERMを子へ転送せず、旧php-fpmが9000を握ったまま残存し次回起動が Address in use で失敗する自己増殖ループに陥っていた。execでphp-fpmをPID1にしシグナルを直接受けさせ、-Fで必ずフォアグラウンド起動にする。

README.md

@@ -867,6 +867,24 @@ composer:
     - "autoconf"
 ```
 
+### php-fpm が CrashLoopBackOff／全リクエストが 502（`Address in use` / `unsupported FastCGI protocol version: 60`）
+
+**症状**: php-fpm コンテナが `CrashLoopBackOff` になり、nginx ログに `upstream sent unsupported FastCGI protocol version: 60`、php-fpm ログに次が出る。
+
+```
+[ERROR] unable to bind listening socket for address '9000': Address in use (98)
+[ERROR] FPM initialization failed
+```
+
+**原因**: php-fpm が 9000 を bind できず起動失敗し、nginx が非 FastCGI 応答を受けて 502 になる。v8.5.9-c 以前は php-fpm を setup シェルの子プロセスとして起動していたため、コンテナ再起動時に PID1 のシェルが `SIGTERM` を子へ転送せず、旧 php-fpm が残存して 9000 を握ったまま次回起動が二重 bind で失敗する自己増殖ループに陥ることがあった。
+
+**対策**: **v8.5.9-d 以降にアップグレードする**（起動を `exec php-fpm -F` に変更済み。php-fpm が PID1 になりシグナルを直接受けて 9000 を確実解放、`-F` で必ずフォアグラウンド起動）。アップグレード後も残存プロセスを持つ既存 pod が残る場合は作り直す。
+
+```bash
+helm upgrade <リリース名> cafepieters/phpfpm --version 8.5.9-d -f values.yaml
+kubectl delete pod -n <namespace> -l app.kubernetes.io/name=phpfpm
+```
+
 ### データベース接続エラー
 
 **確認**: