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で必ずフォアグラウンド起動にする。

CLAUDE.md

@@ -26,6 +26,12 @@ Websites 組織の各サイト（e-learn.jp / fcdomain.com / hotels / tskholding
 
 ## チャート改修履歴
 
+### php-fpm を `exec php-fpm -F` で起動しCrashLoopBackOffを修正（2026-09-06, v8.5.9-d）
+
+setup シェル末尾の `php-fpm`（シェルの子プロセス）を **`exec php-fpm -F`** に変更。selenium 有効構成（hotels）で php-fpm が `unable to bind ... '9000': Address in use` を出して永続 CrashLoopBackOff になり、nginx が非FastCGI応答を受けて全リクエスト502（`unsupported FastCGI protocol version: 60`）になる障害の修正。原因は php-fpm が setup シェルの子で、コンテナ PID1 のシェルが `SIGTERM` を子へ転送しないため、コンテナ再起動時に旧 php-fpm が残存し 9000 を握ったまま次回起動が二重 bind で失敗する自己増殖ループ。`exec` で php-fpm を PID1 にしてシグナルを直接受けさせ（停止時に 9000 を確実解放）、`-F` で `daemonize` 設定に依存せず必ずフォアグラウンド起動にした。全サイト共通で安全（コンテナで php-fpm を動かす定石）。復旧には `helm upgrade` に加え、残存プロセスを持つ既存 pod の削除が必要な場合がある。
+
+**対象ファイル**: `templates/deployment.yaml`, `Chart.yaml`, `README.md`, `CLAUDE.md`, `CHANGELOG-8.5.9-d.md`
+
 ### Ingressのproxy-body-sizeもuploadMaxSizeに連動（2026-08-06, v8.5.9-c）
 
 v8.5.9-bのフォローアップ。`templates/ingress.yaml` で `merge (deepCopy .Values.ingress.annotations) (dict "nginx.ingress.kubernetes.io/proxy-body-size" .Values.uploadMaxSize)` を使い、ユーザーが明示指定していなければ `uploadMaxSize` をIngressの `proxy-body-size` にも自動反映。明示指定があればそちらが優先（sprigのmergeはdst=ユーザー指定annotationsが優先、srcのデフォルト値は不足分のみ補う）。これで `uploadMaxSize` 1箇所でnginx・PHP・Ingressの3箇所すべてが揃う。