phpfpm/CHANGELOG-8.5.9-d.md

Changelog - Version 8.5.9-d

不具合修正

php-fpm を exec php-fpm -F で起動（CrashLoopBackOff / 502 の修正）

php-fpm コンテナの起動コマンドを、setup シェルスクリプト末尾の php-fpm（シェルの子プロセスとしてフォアグラウンド起動）から exec php-fpm -F に変更しました。

背景（実際に発生した障害）

selenium.enabled: true の構成（例: hotels / booking.e-stay.jp）で、php-fpm コンテナが次のエラーで永続的に CrashLoopBackOff に陥る事象が発生しました。

[NOTICE] Failed implicitly binding to ::, retrying with 0.0.0.0
[ERROR] unable to bind listening socket for address '9000': Address in use (98)
[ERROR] FPM initialization failed

php-fpm が 9000 を bind できず起動に失敗するため、nginx が fastcgi_pass 127.0.0.1:9000 に投げても FastCGI ではない応答が返り、upstream sent unsupported FastCGI protocol version: 60 として 全リクエストが 502 になります（60 = <、= 9000 を握っている別プロセスが HTML 等を返している）。

原因

起動コマンドが sh -c "<setup> ... php-fpm" の形で、php-fpm が setup シェルの子プロセスになっていた。コンテナ PID1 はシェルであり、シェルは既定で受け取った SIGTERM を子プロセスへ転送しない。そのためコンテナ（php-fpm コンテナのみ）の再起動時に、PID1 のシェルだけが先に終了し、旧 php-fpm が一時的に残存して 9000 を握ったままになることがある。この状態で新しい php-fpm が起動すると Address in use で失敗 → 再起動 → 同じ残存 → という自己増殖ループに入り、CrashLoopBackOff から復帰できなくなる。selenium サイドカーは 9000 を使用しておらず無関係（別 pod でのポート占有調査でも確認済み）。

対応

• exec php-fpm … php-fpm が setup シェルを置き換えてコンテナの PID1 になる。kubelet からの SIGTERM/SIGKILL が php-fpm 本体へ直接届き、停止時に 9000 が確実に解放されるため、次回起動での二重 bind が起きない。
• -F（--nodaemonize）… php-fpm.conf の daemonize 設定に依存せず、必ずフォアグラウンドで起動する（master が背後に残る事故を防ぐ）。

これは全サイト共通で安全な変更（コンテナ内で php-fpm を動かす際の定石）であり、既存の正常稼働サイトの挙動は変わりません。

復旧手順（重要）

チャートを 8.5.9-d に上げても、既存 pod のネットワーク名前空間に残存プロセスがある場合は、その pod を作り直してクリーンな状態にする必要があります。helm upgrade で新しい pod に置き換わりますが、置き換わらない場合は crashloop 中の pod を明示的に削除してください。

helm upgrade <リリース名> cafepieters/phpfpm --version 8.5.9-d -f values.yaml
# 置き換わらない場合:
kubectl delete pod -n <namespace> -l app.kubernetes.io/name=phpfpm

対象ファイル: templates/deployment.yaml, Chart.yaml, README.md, CLAUDE.md, CHANGELOG-8.5.9-d.md

アップグレード手順

helm repo update
helm upgrade <リリース名> cafepieters/phpfpm --version 8.5.9-d -f values.yaml

---

リリース日: 2026-09-06 担当: プロサーバーエンジニア（Claude）