タグ: PHP-FPM

PHP「php2shell」脆弱性への恒久的対応:PHP8.3-FPMを更新した際のondrej/phpの一時的退避とロールバック

前項で書いた

「php2shell」(CVE-2026-109618、CVE-2026-109619)

への恒久的対応として、PPA提供の php8.3(バージョン 8.3.35)から、Ubuntu公式の修正版(8.3.6-0ubuntu0.24.04.13)へとロールバック・パッチ適用したときの作業メモです。

概要

Ubuntu 24.04 LTS(noble)環境において、php2shell 脆弱性への対応として Ubuntu 公式セキュリティリポジトリの PHP 修正版を適用しようとしたところ、サードパーティリポジトリのパッケージが優先され、通常のパッケージ更新では修正版へ切り替わらない事象が発生しました。

原因調査の結果、ppa:ondrej/php の PHP パッケージ(8.3.35)がインストール済みかつ更新候補として選択されていることを確認しました。APTの仕様上、バージョン番号が大きいPPA版が優先されていたため、PPAをパージして Ubuntu 公式パッケージへロールバックすることでパッチ適用を完了させました。

本記事では、発生した問題、原因調査、ロールバック手順、パッチ適用確認および復旧手順を記録します。

環境

  • OS:Ubuntu 24.04 LTS(noble)
  • 対象パッケージ:PHP 8.3
  • サードパーティリポジトリ:ppa:ondrej/php
  • ロールバック先:Ubuntu 公式セキュリティリポジトリ(noble-security)
  • PHP-FPM:php8.3-fpm
  • Webサーバー:Apache
  • 発生日時:2026年10月22日 02:54 JST
  • 関連事象:PHPパッケージ更新時にPPA側で503エラーが発生。PHP更新後にPHP-FPMおよびWebサイトの動作を検証。

さっくりとした手順

  1. PHPの脆弱性対応パッケージが更新されない事象を確認します。
  2. 一時的に Ubuntu 公式セキュリティリポジトリを直接参照する設定を追加して検証します。
  3. apt-cache policy で PHP のインストール済みバージョンと候補バージョンを確認します。
  4. ppa:ondrej/php のパッケージ(8.3.35)が更新を妨げていることを特定します。
  5. ppa-purge を導入し、PHP PPAをパージして公式パッケージへロールバックします。
  6. PHPのバージョンと関連パッケージを確認します。
  7. changelog から該当の CVE 修正パッチが含まれていることを確認します。
  8. PHP-FPMとWebサーバーを再起動します。
  9. PHP-FPMのソケット、拡張モジュール、Webサイトの応答を確認します。
  10. 一時的なAPT設定を整理し、必要に応じてPPAを再登録します。

特記事項

筆者の好みでaptitudeを用いています。必要に応じてaptに切り替えてください。

1. 発生した問題と初期事象

1.1. 脆弱性パッチが適用されない

php2shell 脆弱性への対応として、Ubuntu 公式セキュリティリポジトリ(noble-security)で配信される修正版パッケージを適用しようとしました。

しかし、以下のコマンドを実行しても、期待した PHP の更新が行われませんでした。

sudo aptitude update
sudo aptitude upgrade

一時的に security.ubuntu.com を直接参照する設定を追加して検証しましたが、更新対象として認識されない状態が続きました。

1.2. PPA側の応答遅延と503エラー

パッケージ更新を試みた際、ppa:ondrej/php 側の応答が一時的に滞り、リポジトリへのアクセスで 503 Service Unavailable が発生しました。

※この事象は、運用中のWebサイトで発生したエラーではなく、PHPパッケージの取得元である外部PPAサーバー側の応答遅延に関するものです。

PPA側の修正パッケージ配信を待たずに即時保護を図るため、Ubuntu公式セキュリティリポジトリの修正版へ切り替えるべく、PPAのパージによるロールバックを実施しました。

※これは緊急的な安全確保のための対処です。記事の後半に再び ppa:ondrej/php に戻す手順も記載しています※

2. 原因調査:APTの候補バージョンを確認

2.1. apt-cache policyを実行

apt-cache policy php8.3

実際の出力結果:

php8.3:
  インストールされているバージョン: 8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  候補:               8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  バージョンテーブル:
 *** 8.3.35-1+ubuntu24.04.1+deb.sury.org+1 500
        500 [https://ppa.launchpadcontent.net/ondrej/php/ubuntu](https://ppa.launchpadcontent.net/ondrej/php/ubuntu) noble/main amd64 Packages
        100 /var/lib/dpkg/status
     8.3.6-0ubuntu0.24.04.13 500
        500 [http://security.ubuntu.com/ubuntu](http://security.ubuntu.com/ubuntu) noble-security/main amd64 Packages
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble-updates/main amd64 Packages
     8.3.6-0ubuntu0.24.04.12 500
        500 [http://security.ubuntu.com/ubuntu](http://security.ubuntu.com/ubuntu) noble-security/main amd64 Packages
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble-updates/main amd64 Packages
     8.3.6-0maysync1 500
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble/main amd64 Packages

2.2. 原因を特定

実測結果から、以下の状態を確認しました。

  • インストール済みバージョン:8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  • APTの候補バージョン:同じく 8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  • Ubuntu公式セキュリティ版:8.3.6-0ubuntu0.24.04.13
  • PPA版と公式版のAPT優先度:いずれも 500

PPA版と公式版のAPT優先度は同じ(500)ですが、バージョン番号の比較(8.3.35 > 8.3.6)により、APTはPPA版を「より新しい最新版」と判定し、候補として固定していました。

その結果、Ubuntu公式セキュリティリポジトリに修正版が存在していても、APTからは「古いバージョンへのダウングレード」とみなされ、通常の更新では公式版への切り替えが行われない状態になっていました。

3. PPAのパージと公式パッケージへのロールバック

3.1. ppa-purgeをインストール

sudo aptitude install -y ppa-purge

3.2. PHP PPAをパージ

sudo ppa-purge ppa:ondrej/php

PPAを無効化し、関連パッケージを一括でUbuntu公式リポジトリのバージョン(8.3.6系列)へロールバックします。
※途中でパッケージの置き換えに関する確認([Y/n])が表示されたら、Y を入力して続行します。

3.3. 公式パッケージのインストール・整合性確保

ppa-purge の依存関係解決によって本体や FPM が外れてしまうケースを防ぐため、公式リポジトリから必要な主要パッケージが揃っていることを確実にします。

sudo aptitude install -y php8.3 php8.3-cli php8.3-fpm

→ ただし、実際に必要な PHP 拡張モジュールも別途確認してください。

php -v

実行結果:

PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.6, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.6, Copyright (c), by Zend Technologies

3.4. PHP関連パッケージの状態を確認

dpkg -l | grep php8.3

PHP本体、PHP-FPM、必要な拡張モジュールがすべて 8.3.6-0ubuntu0.24.04.13 に揃っていることを確認します。

3.5. 脆弱性に対応したパッチであることを確認

外部サーバーへの通信を行わず、ローカルに解凍された変更履歴から該当の CVE 修正を確認します。

zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -C 10 "CVE-2026-109618"

確認結果:

php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium

  * SECURITY UPDATE: Remote RCE via state corruption issue
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
      bailout in Zend/tests/bug40770.phpt, Zend/tests/bug54268.phpt,
      Zend/tests/bug76846.phpt,
...
      tests/basic/oom_rfc1867_upload_progress.phpt,
      tests/output/oom_in_internal_output_handler.phpt.
    - CVE-2026-109618
    - CVE-2026-109619

 -- Marc Deslauriers <marc.deslauriers@ubuntu.com>  Mon, 19 Oct 2026 11:16:58 -0400

パッチ(CVE-2026-109618_109619.patch)が確実に組み込まれていることを確認できました。

4. PHP-FPMとWebサーバーの復旧

4.1. PHP-FPMを再起動

sudo systemctl restart php8.3-fpm

4.2. PHP-FPMの稼働状態を確認

sudo systemctl status php8.3-fpm --no-pager

Active: active (running) となっていることを確認します。

4.3. Apacheを再起動

sudo systemctl restart apache2

Apacheが正常に稼働していることを確認します。

5. 動作検証

5.1. PHP-FPMのソケットを確認

ls -la /run/php/php8.3-fpm.sock

ソケットファイルが存在し、WebサーバーとPHP-FPM間の通信路が正常であることを確認します。

5.2. PHPの拡張モジュールを確認

php -m

アプリケーションで必要な拡張モジュールがロードされていることを確認します(mbstring, mysqli, xml, curl 等)。

※PPA削除時に外れたモジュールがある場合は、公式リポジトリから個別に追加します。

sudo aptitude install php8.3-<module_name>

5.3. Webサイトへのアクセスを確認

curl -I [https://example.com/](https://example.com/)

HTTPレスポンスを確認し、503 Service Unavailable や 502 Bad Gateway が発生せず正常(200 OK など)に応答することを確認します。ブラウザからも主要機能の動作を検証します。

6. PPAの再有効化

6.1. PPAを継続利用する場合の再登録

将来的にPPA側の修正パッケージが配信され、PPA環境へ復帰させる場合は以下の手順で再有効化します。

sudo add-apt-repository ppa:ondrej/php
sudo aptitude update

6.2. 再登録後の候補バージョン確認

apt-cache policy php8.3

PPA側で修正版(CVE対応済みビルド)が提供されていることを確認した上でアップグレードを実施します。

apt list --upgradable 2>/dev/null | grep php8.3
sudo aptitude upgrade

まとめ

今回の事象は、Ubuntu公式セキュリティリポジトリにパッチが配信されていたにもかかわらず、ppa:ondrej/php のパッケージ(8.3.35)がバージョン数値の優先度によってAPTの更新候補を占有していたことが原因でした。

apt-cache policy で優先度と候補を正確に把握し、緊急度に応じて ppa-purge による公式版への一時ロールバックを選択したことで、即座に脆弱性を塞ぎつつサービスの正常稼働を維持することができました。

PHP「php2shell」脆弱性への緊急暫定対応:PHP-FPMのSession Upload Progress無効化(追記に恒久的対応策を記載)(更に追記:CVE-2026-115560にも有効)

更に更に追記 2026/10/23 22:21

本記事でのUpload Progress無効化は、CVE-2026-115560にも有効だという点を添えておきます。

更に追記 2026/10/22 4:02

修正版にアップデートしました。

追記2026/10/21 18:25

2026/10/21 18:25現在、筆者vpsでは念には念を入れてphp-fpmを暫定停止しています。

これは付け焼き刃では対処できないと判断。

sudo systemctl stop php8.3-fpm

で止めています。

→ 修正版が出たために再開しています

概要

2026年10月21日、PHPの重大な脆弱性として報じられた「php2shell」(CVE-2026-109618、CVE-2026-109619)への暫定対応として、PHP-FPMのSession Upload Progress機能を無効化します。

本対応では、session.upload_progress.enabled を Off に設定し、PHP-FPMへ反映しますが、これは本当に緩和策でしかないようでしたが……

CVE-2026-115560の暫定措置としては依然として推奨される策のようです。

2026/10/21 20:27 追記

以下、Geminiによる要約

1. 一体どういう攻撃なのか?

「細工したHTTPリクエストをWebサイトに送るだけで、外部からサーバーのOSコマンドを実行されてしまう」攻撃です。

  • 攻撃の手口:
    攻撃者がWebブラウザやツール経由で特殊なパラメータ(セッション管理やマルチパートフォームの処理に関わるリクエスト)を送信します。
  • 発生する問題:
    PHPコア(C言語で書かれたエンジン部分)内部でメモリ破壊が発生し、Webサーバーの権限で任意のプログラム(シェルなど)を遠隔実行されます。
  • 結果:
    サーバーが丸ごと乗っ取られ、ランサムウェアの設置、データ漏洩、他サイトへの踏み台攻撃などに悪用されます。

2. 大騒ぎしている理由

主に以下の4つの理由から、世界中のエンジニアやセキュリティ企業(watchTowr、各国のCERT等)が大騒ぎしています。

  1. 深刻度スコアが最大級(CVSS 9.2 〜 10.0)
    認証(ログイン)不要、事前の権限不要で、外部ネットワークから直接狙えるため、危険度が最高レベルに設定されています。
  2. 影響範囲が広すぎる
    PHP 5系から8系に至るまで非常に幅広いバージョンが影響を受け、WordPress、Laravel、EC-CUBEなど、Web上の膨大なシステムが標的になり得ます。
  3. アプリ側の改修や設定変更では防ぎきれない
    PHPスクリプト(WordPressやPHPコード自体)の書き方で防げる問題ではなく、PHPエンジンそのもののバグです。php.ini で session.upload_progress.enabled を無効化するなどの緩和策も議論されましたが、完全な遮断には至らず「パッチ適用以外に根本解決がない」と判明したためです。
  4. PoC(実証コード)がパッチ前に出回り始めた
    公式パッチの公開直前(ゼロデイ/準ゼロデイ状態)の段階で、すでに悪用を試みる検証コードや解析情報がネット上に出回り始め、攻撃の自動ボット化が危惧されたためです。

上記理由により、本設定変更は暫定的な緩和策であり、脆弱性そのものの修正を保証するものではありません。正式な修正版PHPが提供されたら、対象バージョンと修正状況を確認したうえで更新します。

また、今回の対応前にApacheのModSecurity CRSが不審なリクエストをHTTP 403で遮断したことを確認しています。WAFによる防御とPHP実行環境の対策を重ね、複数の防御層を維持します。

環境

  • OS:Ubuntu 24.04 LTS
  • Webサーバー:Apache
  • PHP:8.3
  • PHP実行方式:PHP-FPM
  • PHP-FPM設定ファイル:/etc/php/8.3/fpm/php.ini
  • 対象設定:session.upload_progress.enabled
  • 対応目的:脆弱性に対する暫定的なリスク低減

14:00の時点で実施した、さっくりとした手順

  1. PHP-FPMの現在の設定値を確認します。
  2. PHP-FPMの設定ファイルをバックアップします。
  3. session.upload_progress.enabled を Off に変更します。
  4. PHP-FPMの設定を検査します。
  5. PHP-FPMを再読み込みします。
  6. 設定値とサービスの状態を確認します。
  7. Web経由での設定反映とアップロード機能を確認します。
  8. 正式な修正版PHPの公開状況を確認し、更新します。

詳細手順

1. 現在の設定値を確認します

PHP-FPMの設定値を確認します。

sudo php-fpm8.3 -i | grep -i 'session.upload_progress.enabled'

今回の確認結果は以下のとおりでした。

session.upload_progress.enabled => On => On

設定ファイル上では該当行がコメントアウトされていました。

;session.upload_progress.enabled = On

先頭の ; はコメントを示すため、この行自体は設定として適用されません。PHPのデフォルト値が On であるため、コメントアウトされていても機能が無効化されているとは限りません。

実際の設定値を確認し、無効化が必要であることを判断します。

2. 設定ファイルをバックアップします

変更前に、PHP-FPMの設定ファイルをバックアップします。

sudo cp -a /etc/php/8.3/fpm/php.ini /etc/php/8.3/fpm/php.ini.bak-20261021

バックアップファイルが作成されたことを確認します。

ls -l /etc/php/8.3/fpm/php.ini.bak-20261021

設定変更により問題が発生した場合は、このバックアップから元の設定へ切り戻します。

3. Session Upload Progressを無効化します

設定ファイルを編集します。

sudoedit /etc/php/8.3/fpm/php.ini

以下の設定項目を探します。

;session.upload_progress.enabled = On

コメントアウトを解除するだけではなく、値を Off に変更します。

session.upload_progress.enabled = Off

同じ設定項目を重複して追加しないようにします。

変更後、差分を確認します。

sudo diff -u /etc/php/8.3/fpm/php.ini.bak-20261021 /etc/php/8.3/fpm/php.ini

意図した設定項目だけが変更されていることを確認します。

4. PHP-FPMの設定を検査します

設定ファイルの構文を検査します。

sudo php-fpm8.3 -t

正常な場合は、設定ファイルのテストに成功した旨が表示されます。

エラーが表示された場合は、PHP-FPMを再読み込みせず、設定ファイルを修正します。

5. PHP-FPMへ設定を反映します

設定検査に成功したら、PHP-FPMを再読み込みします。

sudo systemctl reload php8.3-fpm

続いてサービスの状態を確認します。

systemctl status php8.3-fpm --no-pager

サービスが正常に稼働していることを確認します。

6. 設定値を再確認します

PHP-FPMの設定値を再確認します。

sudo php-fpm8.3 -i | grep -i 'session.upload_progress.enabled'

期待する結果は以下のとおりです。

session.upload_progress.enabled => Off => Off

ただし、このコマンドは新しく起動したPHP-FPMプロセスの設定を確認するものであり、稼働中のWebリクエストが使用する設定値を直接保証するものではありません。

必要に応じて、Web経由でPHPの設定値を確認します。確認用スクリプトを公開する場合は、外部からアクセスできないように制限し、確認後は必ず削除します。

7. Webアプリケーションの動作を確認します

設定反映後、対象のWebアプリケーションが正常に動作することを確認します。

  • Webサイトの表示
  • ログインとセッション維持
  • ファイルアップロード
  • アップロード後のファイル処理
  • ApacheとPHP-FPMのエラーログ

通常のファイルアップロード自体は、この設定変更によって原則として無効になりません。ただし、PHPのSession Upload Progress機能に依存した進捗表示などには影響する可能性があります。

作業上の注意

影響範囲

session.upload_progress.enabled = Off にすると、PHPがセッションにアップロード進捗情報を記録する機能が無効になります。

通常のファイルアップロード、ログイン、セッション管理などは、この設定変更だけで通常は影響を受けません。ただし、進捗情報を利用するアプリケーションについては動作確認が必要です。

切り戻し

変更後にアプリケーションの動作不良などが発生した場合は、バックアップから設定を復元します。

sudo cp -a /etc/php/8.3/fpm/php.ini.bak-20261021 /etc/php/8.3/fpm/php.ini

復元後、設定を検査します。

sudo php-fpm8.3 -t

検査に成功したら、PHP-FPMを再読み込みします。

sudo systemctl reload php8.3-fpm

最後にサービスの状態とWebアプリケーションの動作を確認します。

なお、切り戻しによって設定値が On に戻る場合、暫定緩和策も解除されます。切り戻しは必要な場合に限り、影響とリスクを確認して実施します。

根本対策

本対応は暫定的な緩和策です。正式な修正版PHPが公開されたら、PHP公式およびUbuntuのセキュリティ情報を確認します。

Ubuntuでは修正がバックポートされる場合があるため、バージョン番号だけで判断せず、使用中のリリースに対する修正状況を確認します。

修正版が提供されたら、実際にWebアプリケーションが使用しているPHP実行環境を更新し、動作確認を実施します。

まとめ

PHPの設定ファイルで該当項目がコメントアウトされていても、機能が無効になっているとは限りません。PHPのデフォルト値が On であれば、コメントアウトされた状態でも機能は有効です。

今回の対応では、設定ファイルの記述だけで判断せず、実際の設定値を確認したうえで Off を明示し、PHP-FPMへの反映と動作確認を行います。

WAFによるリクエスト遮断、PHP実行環境の暫定対策、修正版への更新を組み合わせ、単一の防御機構に依存しない構成を維持します。

Ubuntu26.04にPHP8.5/PHP8.5-FPMをインストール。

概要

Ubuntu 26.04でWebアプリ(Nextcloudを想定)を動かす際の柱であるPHPのインストールを行います。

盛大にはまったポイント

2026/04/23にリリースされた26.04。導入されるミドルウェアの最新性がキモでした。

筆者が前項でやったレポジトリ追加は「26.04には対応してない。そもそもミドルウェアが合ってない」など言われましたが、
「リポジトリを追加するまでもなく最新版がインストールされる」ことに気づきませんでした。

さっくりとした手順

  1. システムを最新化します。
  2. PHP 8.5本体を導入します。
  3. 必須モジュールをインストールします。
  4. PHP-FPMを導入します。
  5. 高速化設定を行います。(OPcache, APCu周り)
  6. 設定を反映します。

システムの更新

まずは標準リポジトリを最新の状態にします。

sudo aptitude update

PHP 8.5 本体と Redis サーバーのインストール

メタパッケージ(バージョン指定なし)を使用することで、OSが最適な 8.5 系を自動選択します。

sudo aptitude install php php-fpm php-common php-cli php-readline redis-server

当初筆者はPHP8.4を選択していたのですが、そこが盛大なはまりポイントでした。(PHPの動向を追っていなかったという失態もあります)

Nextcloud 必須・推奨拡張モジュールのインストール

Nextcloudの動作に不可欠なモジュール群を一括で導入します。

sudo aptitude install php-{bcmath,bz2,curl,gd,gmp,intl,ldap,mbstring,mysql,sockets,xml,zip,imagick,redis,apcu,memcached}

Apache 連携設定 (PHP-FPM版)

Apacheで PHP 8.5 を FPM 経由で動作させる設定です。

sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.5-fpm
sudo systemctl restart apache2

5. PHP 8.5 高速化設定 (OPcache / APCu)

Nextcloudの警告を消し、パフォーマンスを最大化するための設定です。

  • OPcache設定の作成
cat <<- __EOF__ | sudo tee /etc/php/8.5/mods-available/opcache.ini > /dev/null
; configuration for php opcache module
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=256
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__

→ 既にあるファイルを上書きます。(切り戻し想定せず)

  • APCu設定の作成
cat <<- __EOF__ | sudo tee /etc/php/8.5/mods-available/apcu.ini > /dev/null
extension=apcu.so
[apcu]
apc.enabled=1 apc.shm_size=32M apc.ttl=7200 apc.enable_cli=1 apc.serializer=php __EOF__

 設定の有効化

sudo phpenmod opcache apcu

このphpenmodもハマりポイントでした。従来の ln -sではなく、専用コマンドを用いることでfpm / cli / apache-mod でも安定した運用が可能になります。

サービスの再起動と確認

sudo systemctl restart php8.5-fpm
sudo systemctl restart redis-server
sudo systemctl restart apache2
  • バージョンの確認
php -v

※ with Zend OPcache v8.5.4 等 と表示されれば正解です。

備考:PHPを用いるWebアプリ設定の確認

Apacheの各サイト設定ファイル (/etc/apache2/sites-available/*.conf) 内で、必ず 8.5 のソケットを指定してください。

<FilesMatch \.php$>
&nbsp; &nbsp; SetHandler "proxy:unix:/var/run/php/php8.5-fpm.sock|fcgi://localhost/"
</FilesMatch>

これを入れないと、

The requested URL was not found on this server.   
    
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

の非情なるメッセージが返ってきます。

ユースケース:PHP-FPMプール設定引き上げによるNextcloudのレスポンス改善

環境

  • Nextcloud 31系
  • PHP 8.3
    • PHP-FPM 8.3
  • Redis / APCUなどによる
  • Apache 2.4
  • Ubuntu 24.04
  • MySQL 8
  • メモリ6GB
  • 4 core CPU

事象

Nextcloud Talkを含めたレスポンスが非常に悪いという状況。具体的には

  • トップページがなかなかロードされない。
  • 各画面の遷移状態が悪い。
  • 画像をクリックしても表示に時間がかかる。(分単位であることも)

free -hでもメモリ圧迫という様子を見せず、topをたたいても異常なし。

何よりも、同一サーバに同居する

  • Growi
  • Redmine
  • BookStack

などが正常に動いていて、これらはレスポンスも良好。サーバの性能ではなく、サーバ以外のところに原因があると考え、調査開始です。

原因究明

答えは/var/log配下のphp8.3-fpm.logに現れていました。

[04-Oct-2025 17:32:36] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[04-Oct-2025 18:45:55] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[04-Oct-2025 21:28:57] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

これにより、PHPのリクエストを処理するワーカープロセスの数が上限(5)に達し、リクエストが滞留していることがパフォーマンス低下の直接的な原因だと特定しました。

これが分かれば、後は実際の対処です。

事象改善:さっくりとした手順

  1. PHP-FPMのプール設定ファイルのバックアップを取ります。
  2. 設定ファイルを編集してワーカープロセスの上限数や他の関連する値を引き上げます。
  3. 設定ファイルを反映させるため、各種サービスを再起動します。
  4. 事象の解決を確認します。

設定ファイルのバックアップ

  • ファイルバックアップ
sudo cp -pi /etc/php/8.3/fpm/pool.d/www.conf /path/to/backup/directory/www.conf.$(date +%Y%m%d)

※php-fpmの設定値は、入れているPHPのバージョンによって異なります。自分の環境に合わせたものに修正してください。

 → /home/hoge/backupなど、任意のバックアップディレクトリを指定します。

  • ファイルバックアップ確認
diff -u /path/to/backup/directory/www.conf.$(date +%Y%m%d) /etc/php/8.3/fpm/pool.d/www.conf

 → エラーがなければバックアップが取れています。

備考:なぜdiffを用いてバックアップの確認をするのか?

  • ls -lよりも確実に、元ファイルとバックアップファイルがあるか「両方のファイル」で確認を取るため。
  • 編集後、「どのような編集を行ったのか?」を同じコマンドで確認を取る。
    • 「バックアップ」-「設定ファイル」の順番とすることで、後のdiffの編集を行った、追記を行った箇所が+で表示されます。(同様に削った箇所が-で表示)

特に、設定ファイルの修正は非常にデリケートな問題であり、下手な設定がサーバ全体のシステムダウンを引き起こします。このため、変更管理や後のトラブルの追跡を兼ねてのバックアップはサーバメンテナンスの黄金律として体に覚え込ませましょう。

ファイルの修正

  • ファイルの修正

上記、バックアップを取った後の 元ファイル /etc/php/8.3/fpm/pool.d/www.conf を、管理者権限で、自身の教義・信仰に基づいたエディタで修正します。

こちらの設定値は、aptなどでのパッケージ管理システムでのインストールであれば、

pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

となっていることが多いです。これを、以下のように修正しましょう。

pm.max_children = 15
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6

※ サーバ環境などにより、随時、修正を行ってください。

修正後、保存を行います。

  • diffによる差分確認
diff -u /path/to/backup/directory/www.conf.$(date +%Y%m%d) /etc/php/8.3/fpm/pool.d/www.conf

以下のような差分を確認します。

; Note: This value is mandatory.
-pm.max_children = 5
+pm.max_children = 15

 ; The number of child processes created on startup.
 ; Note: Used only when pm is set to 'dynamic'
 ; Default Value: (min_spare_servers + max_spare_servers) / 2
-pm.start_servers = 2
+pm.start_servers = 4
 ; The desired minimum number of idle server processes.
 ; Note: Used only when pm is set to 'dynamic'
 ; Note: Mandatory when pm is set to 'dynamic'
-pm.min_spare_servers = 1
+pm.min_spare_servers = 2
 ; The desired maximum number of idle server processes.
 ; Note: Used only when pm is set to 'dynamic'
 ; Note: Mandatory when pm is set to 'dynamic'
-pm.max_spare_servers = 3
+pm.max_spare_servers = 6 
 ; The number of rate to spawn child processes at once.
 ; Note: Used only when pm is set to 'dynamic' 

このように、修正前が-の行、修正後が+の行で修正されていることが分かります。この数値や設定以上に重要なのは「変なスペースや意図した設定以外の情報が含まれていないか?」を、自分の修正した記憶を頼りにすることではなく、コマンドという絶対的な第三者の目で確認することです。

設定反映

PHP-FPMだけでなく、前段のApacheもサービス再起動を行います。

  • Apacheサービス再起動
sudo systemctl restart apache2.service
  • Apacheサービス再起動後確認
systemctl status apache2.service

→ active(running)を確認します。

  • PHP-FPMサービス再起動
sudo systemctl restart php8.3-fpm.service
  • PHP-FPMサービス再起動後確認
systemctl status php8.3-fpm.service

→ active(running)を確認します。

事象改善確認

再びNextcloudにアクセスし、事象が改善したことを確認できれば設定完了です。

余談:なぜこの事象が起きたか?

Nextcloudの利用頻度が高まったからに尽きます。Talkをスマートフォンアプリでも利用したり、データが増えたことで、PHP-FPMの処理能力が追いつかなかったのでしょう。

利用状況に合わせて、ボトルネックを特定し、修正を加えて改善を施していくというのもまた、サーバ運用の苦しくも楽しいところです。

Ubuntu24.04にPiwigoインストール。(PHP-FPM対応版)

概要

画像管理に特化したオープンソースのフォトギャラリー「Piwigo」。Ubuntu24.04での構築メモです。

前提/環境

  • Ubuntu 24.04の基本的な設定が完了している。
  • Apache, MySQL, PHP-FPMがインストール済みである。
    • PHP及びPHP-FPMは8.3
    • Apacheの実行ユーザはwww-data
  • Piwigoを公開するドメイン名と、対応するSSL証明書が用意されている。

さっくりとした手順

  1. データベースの作成: Piwigoが使用するMySQLデータベースとユーザーを作成します。
  2. PHP拡張機能の確認: Piwigoの動作に必要なPHP拡張機能がインストールされているか確認します。
  3. Piwigoの配置: プログラム本体をサーバーに配置します。
  4. Apacheの設定: ApacheがPiwigoを正しく表示できるように設定します。
  5. Webインストーラーの実行: ブラウザから初期設定を完了させます。

データベースの作成

  • MySQLログイン
sudo mysql -u root -p
  • DB作成
CREATE DATABASE piwigo CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  • ユーザー作成と権限付与(【】内は強固なパスワードに置き換えてください)
CREATE USER 'piwigo'@'localhost' IDENTIFIED BY '【YOUR_STRONG_PASSWORD】';
GRANT ALL PRIVILEGES ON piwigo.* TO 'piwigo'@'localhost';
FLUSH PRIVILEGES;
EXIT;
  • DB作成確認
mysql -u piwigo -p

先ほど作成したDBユーザです。

SHOW DATABASES;

作成したDBが表示されることを確認します。

EXIT

確認後、MySQLコンソールから抜けます。

PHP拡張機能の確認・インストール

Piwigoは、画像の処理のためにgdやimagemagickといったPHPの拡張機能を必要とします。
これらがインストールされているか確認します。(ない場合は以下の手順でインストール)

  • 既存のPHP拡張機能で不足しているものをインストールする例
sudo aptitude install php8.3-gd php8.3-imagick php8.3-mysql

筆者の好みに合わせてaptitudeを用いています。必要に応じてaptに読み替えます。

Piwigoの配置

  • Web公開用ディレクトリに移動
cd /var/www/html && pwd

自分の環境に合わせます。(筆者環境/home/www-data)

  • git cloneによる配置
sudo -u www-data git clone https://github.com/Piwigo/Piwigo.git piwigo

piwigoは自分の環境に合わせます。

Apacheの設定

  • ログディレクトリの作成
sudo mkdir -p /var/log/piwigo

自分の環境に合わせます。

  • ディレクトリの権限変更
sudo chown -R www-data:www-data /var/log/piwigo

Piwigo用のApache設定ファイル(例: /etc/apache2/sites-available/piwigo.conf)を以下の内容で作成します。

<VirtualHost *:80>
    # ドメイン名を指定します
    servername photo.example.com
    # HTTPアクセスを強制的にHTTPSにリダイレクトします
    RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName photo.example.com
    # アクセスログ
    CustomLog /var/log/piwigo/piwigo_access.log combined
    # エラーログ
    ErrorLog /var/log/piwigo/piwigo_error.log

    # PHP-FPMと連携するための設定
    <FilesMatch \.php$>
        SetHandler "proxy:unix:/var/run/php/php8.3-fpm.sock|fcgi://localhost/"
    </FilesMatch>
    DocumentRoot /home/www-data/piwigo
    <Directory /home/www-data/piwigo>
        AllowOverride All
        Require all granted
    </Directory>

    #SSL設定
      SSLEngine on
    Protocols h2 http/1.1

    # 推奨されるSSL/TLS設定 (Mozilla Intermediate Compatibility)
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder     on
    SSLCompression          off
    SSLSessionTickets       off # PFSを強化する場合

    # SSL証明書を指定します
    SSLCertificateFile 【SSL証明書のパスを絶対パスで指定】
    # 秘密鍵を指定します
    SSLCertificateKeyFile 【SSL証明書に対応した秘密鍵のパスを絶対パスで指定】

    #セキュリティヘッダー付与
        Header always set Strict-Transport-Security "max-age=63072000"
        Header always set X-Content-Type-Options "nosniff"
        Header always set X-Frame-Options "SAMEORIGIN"
        Header always set X-XSS-Protection "1; mode=block"
</VirtualHost>
  • 設定ファイルの有効化
sudo a2ensite piwigo.conf
  • 設定ファイルの整合性確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • apacheリスタート
sudo systemctl restart apache2.service
  • apacheリスタート確認
systemctl status apache2.service

active(running)を確認します。

Webインストーラーの実行

  1. ブラウザで、設定したドメイン(https://【photo.example.com】)にアクセスします。
  2. Piwigoの初期設定ウィザードが表示されます。
  3. 画面の指示に従い、データベース情報(ステップ1で作成したもの)や、管理者アカウントの情報を入力します。

インストーラーが完了すれば、Piwigoのフォトギャラリーが利用可能になります。

Apache & PHP-FPM 管理スクリプト (引数対応版)。

Webサーバを運用する上で役立ている

  1. Apacheで有効になっているサイトの設定情報を表示
  2. 構文を確認
  3. 問題が無ければApache再起動
  4. 再起動後にステータスを表示する

スクリプト。非常に便利なものでしたが、VPS新調に際してPHP-FPMを導入。

そこで、

  1. PHP-FPMも構文チェックを行う
  2. 他、引数による処理

を改訂しました。(元ネタ:ChatGPT、リファクタリングはdeepseekとGemini)

スクリプト内容

  • apache2-check.sh
#!/bin/bash

#================================================================
# Apache & PHP-FPM 管理スクリプト (引数対応版)
#================================================================
#
# 機能:
# 1. Apacheで有効になっているサイトの設定情報を表示します。
# 2. ApacheとPHP-FPMの設定ファイルの構文をチェックします。
# 3. ApacheとPHP-FPMの再起動を個別に確認し、実行します。
# 4. 再起動後に各サービスのステータスを表示します。
#
# 引数:
#  -y : 確認プロンプトをすべてスキップし、自動で'yes'と応答します。
#  -a : Apacheのみを対象とします。
#  -p : PHP-FPMのみを対象とします。
#  -h : このヘルプを表示します。
#
#================================================================

# --- 設定項目 ---

# Apacheのサイト設定が格納されているディレクトリ
SITES_DIR="/etc/apache2/sites-enabled"

# 操作対象のPHPバージョン (例: "8.3", "8.2", "7.4")
PHP_VERSION="8.3"

# --- 設定ここまで ---


# --- スクリプトの動作を制御するフラグ ---
AUTO_YES=false
RESTART_APACHE=true  # デフォルトでは両方実行
RESTART_PHP=true     # デフォルトでは両方実行
EXCLUSIVE_MODE=false # -a または -p が指定されたかを判定するフラグ

# --- ヘルプ表示関数 ---
usage() {
    echo "Usage: $(basename "$0") [-y] [-a] [-p] [-h]"
    echo "  -y : 確認プロンプトをすべてスキップし、自動で'yes'と応答します。"
    echo "  -a : Apacheのみを対象とします。"
    echo "  -p : PHP-FPMのみを対象とします。"
    echo "  -h : ヘルプを表示します。"
    echo "引数なしの場合は、ApacheとPHP-FPMの両方が対象となります。"
    exit 0
}

# --- 引数解析 ---
while getopts "yaph" opt; do
  case $opt in
    y)
      AUTO_YES=true
      ;;
    a)
      if ! $EXCLUSIVE_MODE; then
          # -a or -p が初めて指定された場合、排他モードにしてデフォルトをリセット
          RESTART_APACHE=false
          RESTART_PHP=false
          EXCLUSIVE_MODE=true
      fi
      RESTART_APACHE=true
      ;;
    p)
      if ! $EXCLUSIVE_MODE; then
          # -a or -p が初めて指定された場合、排他モードにしてデフォルトをリセット
          RESTART_APACHE=false
          RESTART_PHP=false
          EXCLUSIVE_MODE=true
      fi
      RESTART_PHP=true
      ;;
    h)
      usage
      ;;
    \?)
      # 不正なオプション
      usage
      ;;
  esac
done

# PHP-FPMのサービス名とコマンド名を変数から生成
PHP_FPM_SERVICE="php${PHP_VERSION}-fpm"
PHP_FPM_COMMAND="php-fpm${PHP_VERSION}"

#
# サービスを再起動し、ステータスを表示する関数
#
restart_and_check_service() {
    local service_name="$1"
    local service_label="$2" # 表示用の名前
    local confirm_action="n"

    if [ "$AUTO_YES" = true ]; then
        confirm_action="y"
        echo "${service_label} を再起動します... (-yオプションにより自動確認)"
    else
        read -p "${service_label} を再起動しますか? (y/n): " confirm_action
    fi

    if [[ "$confirm_action" =~ ^[Yy]$ ]]; then
        if [ "$AUTO_YES" = false ]; then
          echo "--- ${service_label} を再起動します... ---"
        fi
        if ! systemctl restart "$service_name"; then
            echo "エラー: ${service_label} の再起動に失敗しました。"
        else
            echo "${service_label} が正常に再起動されました。"
            echo
            echo "==== ${service_label} ステータス ===="
            systemctl status "$service_name" --no-pager
            echo "=================================="
        fi
    else
        echo "${service_label} の再起動はキャンセルされました。"
    fi
    echo
}

# スクリプトを root ユーザーで実行しているかチェック
if [ "$EUID" -ne 0 ]; then
    echo "エラー: このスクリプトは root 権限で実行する必要があります。"
    exit 1
fi

# 1. 有効なサイト設定とドメインを表示
# このセクションは引数に関わらず常に表示される情報として実行します
echo "==== 有効なサイト設定ファイル ===="
if [ -z "$(ls -A "$SITES_DIR" 2>/dev/null)" ]; then
    echo "サイト設定が存在しません。"
else
    shopt -s nullglob
    for site in "$SITES_DIR"/*; do
        echo "設定ファイル: $(basename "$site")"
        entries=$(grep -hi -E "^\s*(ServerName|ServerAlias)\s+" "$site" | sed -E 's/^[[:blank:]]+//;s/[[:blank:]]*#.*//' | awk '{
            original_directive = $1
            directive = tolower(original_directive)
            proper_directive = (directive == "servername") ? "ServerName" : \
                               (directive == "serveralias") ? "ServerAlias" : original_directive
            for (i=2; i<=NF; i++) {
                domain = tolower($i)
                sub(/[;,]*$/, "", domain)
                gsub(/^[[:blank:]]+|[[:blank:]]+$/, "", domain)
                if (domain) {
                    printf "%s %s\n", proper_directive, domain
                }
            }
        }' | sort -u)
        if [ -z "$entries" ]; then
            echo "  ※ ServerName/ServerAliasが定義されていません"
        else
            echo "$entries" | sed 's/^/  /'
        fi
        echo
    done
    shopt -u nullglob
fi
echo "=================================="
echo

# 2. 構文チェック
echo "--- 構文チェック ---"
SYNTAX_OK=true

# Apache構文チェック
if [ "$RESTART_APACHE" = true ]; then
    echo "Apache の構文をチェックしています..."
    if ! apachectl configtest 2>&1 | grep -q "Syntax OK"; then
        echo "エラー: Apacheの構文エラーが検出されました。"
        apachectl configtest # エラー詳細を再表示
        SYNTAX_OK=false
    else
        echo "Apacheの構文は正常です。"
    fi
    echo
fi

# PHP-FPMの存在確認と構文チェック
PHP_FPM_ENABLED=false
if [ "$RESTART_PHP" = true ]; then
    if systemctl list-units --type=service --all | grep -q "${PHP_FPM_SERVICE}.service"; then
        if command -v "$PHP_FPM_COMMAND" &>/dev/null; then
            PHP_FPM_ENABLED=true
            echo "${PHP_FPM_SERVICE} の構文をチェックしています..."
            if ! "$PHP_FPM_COMMAND" -t 2>&1 | grep -q "test is successful"; then
                echo "エラー: ${PHP_FPM_SERVICE} の構文エラーが検出されました。"
                "$PHP_FPM_COMMAND" -t # エラー詳細を再表示
                SYNTAX_OK=false
            else
                echo "${PHP_FPM_SERVICE} の構文は正常です。"
            fi
        else
            echo "警告: ${PHP_FPM_SERVICE} サービスは存在しますが、${PHP_FPM_COMMAND} コマンドが見つかりませ
ん。PHP-FPMのチェックはスキップします。"
            RESTART_PHP=false # 実行フラグをオフにする
        fi
    else
        echo "情報: ${PHP_FPM_SERVICE} サービスが見つかりません。PHP-FPM関連の処理はスキップします。"
        RESTART_PHP=false # 実行フラグをオフにする
    fi
    echo
fi

# 構文エラーがあれば処理を中断
if [ "$SYNTAX_OK" = false ]; then
    echo "構文エラーが検出されたため、処理を中断します。"
    exit 1
fi
echo "--------------------"
echo

# 3. サービスの再起動
if [ "$RESTART_APACHE" = false ] && [ "$RESTART_PHP" = false ]; then
    echo "再起動対象のサービスがありません。"
    exit 0
fi

# Apacheの再起動
if [ "$RESTART_APACHE" = true ]; then
    restart_and_check_service "apache2" "Apache"
fi

# PHP-FPMの再起動
if [ "$RESTART_PHP" = true ] && [ "$PHP_FPM_ENABLED" = true ]; then
    restart_and_check_service "$PHP_FPM_SERVICE" "$PHP_FPM_SERVICE"
fi

スクリプトの動き

  1. sudo bash apache2-check.shとすることで
  2. A@acheを起動するか、PHP-FPMを起動するかの2択が生まれます。
  3. -yオプションの場合は全てyにしてプロンプトを省略します。
  4. -aでApacheのみの再起動-pはPHP-FPMのみの再起動

と、柔軟かつやりやすいスタイルへと仕上がりました。

PHP8.3をPHP-FPMで動かすための設定

概要

Nextcloud等のLAMP環境で利用するPHPを、PHP-FPM (FastCGI Process Manager) を使ってApacheと連携させる形でインストール・設定します。
php-fpmを利用すると、PHPの処理がApacheのプロセスから分離されるため、パフォーマンスの向上や、より柔軟なリソース管理が期待できます。

※筆者の好みでaptitudeを用いています。適宜、aptに読み替えてください。

実施した環境

  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8

さっくりとした手順

  1. レポジトリを追加します。
  2. PHPおよびPHP-FPMパッケージをインストールします。
  3. Apacheの連携用モジュールを設定します。
  4. PHPのパフォーマンス設定(OPcache等)を行います。
  5. 各Webサイト(バーチャルホスト)でPHP-FPMを有効化します。
  6. サービスを再起動し、動作を確認します。

手順詳細

レポジトリ追加とアップデート

最新のPHPバージョンを利用するため、ondrej/phpリポジトリを追加します。

  • PHPレポジトリの追加
sudo add-apt-repository ppa:ondrej/php
  • パッケージ全体のアップデート
sudo aptitude update

PHPパッケージのインストール

PHP本体と、php-fpm、そしてWebアプリケーションで一般的に必要とされる拡張機能をインストールします。

  • PHP本体とFPM
sudo aptitude install php8.3 php8.3-fpm
  • 周辺モジュール (APCuとMemcached)
sudo aptitude install memcached php8.3-apcu
  • Webアプリに必要な周辺モジュール (MySQLを使う場合)
sudo aptitude install php8.3-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysql,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml,imagick,gmp,redis-server}
  • インストール確認
php -v

PHP 8.3.xのように、インストールしたバージョンが表示されることを確認します。

Apache連携モジュールの設定

php-fpmでPHPを動かすため、従来のmod_phpを無効化し、代わりにphp-fpmと通信するためのproxy_fcgiモジュールを有効化します。

  • mod_phpを無効化
sudo a2dismod php8.3
  • 必要なモジュールを有効化
sudo a2enmod proxy_fcgi setenvif

OPcacheとAPCuの有効化

Nextcloudなどのアプリケーションでは、パフォーマンス向上のためこれらのキャッシュ設定が推奨(あるいは必須)となります。

  • 設定ファイル待避
sudo mv /etc/php/8.3/mods-available/opcache.ini /path/to/backup/directory/opcache.ini.$(date +%Y%m%d)
sudo mv /etc/php/8.3/mods-available/apcu.ini /path/to/backup/directory/apcu.ini.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。(筆者環境/etc/conf_backup)

  • 設定ファイル差し替え
cat <<- __EOF__ | sudo tee /etc/php/8.3/mods-available/opcache.ini > /dev/null
; configuration for php opcache module
; priority=10
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=256
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__
cat <<- __EOF__ | sudo tee /etc/php/8.3/mods-available/apcu.ini > /dev/null
extension=apcu.so
[apcu]
apc.enabled=1 apc.shm_size=32M apc.ttl=7200 apc.enable_cli=1 apc.serializer=php
__EOF__

※ メモリ量などは環境に合わせます。

各WebサイトでのPHP-FPM連携設定

各WebサイトのApache設定ファイル(.conf)で、PHPへのリクエストをphp-fpmに渡すように設定します。この設定がなければPHPスクリプトをサーバが解釈せず、動きません。

  • 設定例 (/etc/apache2/sites-available/hoge.confなど)
    <VirtualHost>ブロックの中に、以下の<FilesMatch>ブロックを追記します。
    <VirtualHost *:443>
        ServerName hoge.example.com
        # ...

        <FilesMatch \.php$>
            # SetHandlerで、phpファイルのリクエストをFastCGIプロキシに渡す
            SetHandler "proxy:unix:/var/run/php/php8.3-fpm.sock|fcgi://localhost/"
        </FilesMatch>

        # ...
    </VirtualHost>

このSetHandlerディレクティブが、Apacheに来たPHPへのリクエストを、バックグラウンドで動いているphp-fpmのプロセスに転送する役割を担います。

サービスの再起動と動作確認

設定を反映させるため、Apacheとphp-fpmの両方を再起動します。

  • サービス再起動
sudo systemctl restart php8.3-fpm.service
sudo systemctl restart apache2.service
  • 動作確認
    mod_phpは無効化されているため、a2queryではdisabledと表示されるのが正しい状態です。代わりに、php-fpmサービスが稼働していることを確認します。
systemctl status php8.3-fpm.service
`active (running)`と表示されていれば、PHP-FPMの導入と設定は完了です。

Powered by WordPress & Theme by Anders Norén