はじめに
Web サイトのパフォーマンス向上やセキュリティ強化のために、PHP のバージョンアップは欠かせない作業です。今回は、WordPress を運用している Rocky Linux 9 サーバーで、PHP 8.0.30 から PHP 8.3 へアップデートした際の詳細な手順と、その過程で遭遇した数々のエラー、そしてその解決策を記録としてまとめました。
同じような環境で作業される方の参考になれば幸いです。
1. 作業前の環境確認
まず、現在の PHP のバージョンとインストールされているパッケージを確認します。
$ dnf list installed | grep php
php.x86_64 8.0.30-1.el9_2 @System
php-cli.x86_64 8.0.30-1.el9_2 @System
php-common.x86_64 8.0.30-1.el9_2 @System
php-devel.x86_64 8.0.30-1.el9_2 @appstream
php-fpm.x86_64 8.0.30-1.el9_2 @System
php-gd.x86_64 8.0.30-1.el9_2 @appstream
php-intl.x86_64 8.0.30-1.el9_2 @appstream
php-mbstring.x86_64 8.0.30-1.el9_2 @System
php-mysqlnd.x86_64 8.0.30-1.el9_2 @System
php-opcache.x86_64 8.0.30-1.el9_2 @System
php-pdo.x86_64 8.0.30-1.el9_2 @System
php-pear.noarch 1:1.10.13-1.el9 @appstream
php-pecl-zip.x86_64 1.19.2-6.el9 @appstream
php-process.x86_64 8.0.30-1.el9_2 @appstream
php-xml.x86_64 8.0.30-1.el9_2 @System次に、dnfで利用可能な PHP モジュールを確認します。
$ sudo dnf module list php
メタデータの期限切れの最終確認: 3:23:02 前の 2025年07月13日 10時49分59秒 に実施しました。
Rocky Linux 9 - AppStream
Name Stream Profiles Summary
php 8.1 common [d], devel, minimal PHP scripting language
php 8.2 common [d], devel, minimal PHP scripting language
php 8.3 common [d], devel, minimal PHP scripting language
ヒント: [d]efault, [e]nabled, [x]disabled, [i]nstalled
PHP 8.3 が利用可能であることが確認できました。
2. PHP のバージョンアップ手順
ステップ 1: PHP モジュールの切り替え
まず、現在有効な PHP 8.0 モジュールをリセットし、その後 PHP 8.3 モジュールを有効化します。
###現在のPHPモジュールをリセット
$ sudo dnf module reset php -y
メタデータの期限切れの最終確認: 1:06:04 前の 2025 年 07 月 26 日 15 時 03 分 50 秒 に実施しました。
依存関係が解決しました。
行うべきことはありません。
完了しました!PHP 8.3モジュールを有効化
$ sudo dnf module enable php:8.3 -y
メタデータの期限切れの最終確認: 1:06:28 前の 2025 年 07 月 26 日 15 時 03 分 50 秒 に実施しました。
依存関係が解決しました。
パッケージ アーキテクチャー バージョン リポジトリー サイズ
モジュールストリームの有効化中:
php 8.3
トランザクションの概要
完了しました!ステップ 2: PHP パッケージのアップデート
有効化した PHP 8.3 モジュールを使って、インストール済みの PHP パッケージをアップデートします。
$ sudo dnf update -yしかし、このコマンドで以下のエラーが発生しました。
【エラー 1】 dnf updateでの依存関係エラー
エラー:
問題: package python3-leapp-0.19.0-1.el9.noarch from appstream requires leapp-framework-dependencies = 6, but none of the providers can be installed
- installed package leapp-deps-el9-5.0.9-100.202203181036Z.249925a3.master.el9.noarch obsoletes leapp-deps provided by leapp-deps-0.19.0-1.el9.noarch from appstream
- パッケージの最良アップデート候補をインストールできません python3-leapp-0.14.0-1.el8_6.noarch
- インストール済パッケージの問題 leapp-deps-el9-5.0.9-100.202203181036Z.249925a3.master.el9.noarch
(インストール不可のパッケージをスキップするには、'--skip-broken' を追加してみてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)エラーメッセージの指示に従い、--nobest オプションを付けて再度実行します。これにより、最適候補以外のパッケージが選択され、依存関係の問題を回避できる場合があります。
$ sudo dnf update -y --nobest
...
完了しました!無事にアップデートが完了しました。
ステップ 3: サービス再起動とバージョン確認
PHP-FPM と Web サーバー（今回は Nginx）を再起動し、変更を反映させます。
### PHP-FPMの再起動とステータス確認
$ sudo systemctl restart php-fpm
$ sudo systemctl status php-fpm
● php-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; preset: disabled)
Active: active (running) ...Nginxの構文チェックと再起動(とトラブルシュートの始まり)
$ sudo nginx -t
$ sudo systemctl restart nginx
PHP のバージョンを確認します。
$ php -vすると、バージョンは 8.3.19 に上がっていましたが、複数の警告が表示されました。ここからが本格的なトラブルシューティングの始まりです。
3. アップデート後のエラーと解決策
【エラー 2】 imagickモジュールの API バージョン不一致
php -v を実行すると、まずimagickモジュールに関する警告が表示されました。
PHP Warning: PHP Startup: imagick: Unable to initialize module
Module compiled with module API=20200930
PHP compiled with module API=20230831
These options need to match
in Unknown on line 0
...これは、PHP 本体が 8.3（API=20230831）にアップデートされたのに対し、imagickモジュールが古い PHP 8.0（API=20200930）でコンパイルされたままであることが原因です。
解決策: peclを使ってimagickを再インストールし、現在の PHP バージョンに合わせて再コンパイルします。
# 既存のimagickをアンインストール
$ sudo pecl uninstall imagick
uninstall ok: channel://pecl.php.net/imagick-3.7.0
# imagickを再インストール
$ sudo pecl install imagick
...
Build process completed successfully
Installing '/usr/lib64/php/modules/imagick.so'
...
install ok: channel://pecl.php.net/imagick-3.8.0
configuration option "php_ini" is not set to php.ini location
You should add "extension=imagick.so" to php.iniインストール後、指示に従い/etc/php.iniにextension=imagick.soを追記しましたが、これが新たな問題を引き起こしました。
【エラー 3】 imagickモジュールの二重読み込み
php.iniを編集した後、php -vで以下の警告が表示されました。
PHP Warning: Module "imagick" is already loaded in Unknown on line 0
...原因の調査: peclでのインストール時に、/etc/php.d/20-imagick.iniという設定ファイルが自動で作成されていました。それに加えて手動で/etc/php.iniにも記述したため、モジュールが二重に読み込まれていました。
$ grep -r imagick.so /etc/php.ini /etc/php.d/
/etc/php.ini:extension=imagick.so
/etc/php.d/20-imagick.ini:extension=imagick.so解決策: 手動で追記した/etc/php.iniの行を削除し、peclが作成した設定ファイルのみを利用するようにします。
# sedコマンドでphp.iniの最終行を削除
$ sudo sed -i -e '$d' /etc/php.iniこれでimagickに関する警告は解消されました。
【エラー 4】 pdo_sqliteモジュールの読み込み失敗
imagickの問題が解決した後も、pdo_sqliteに関する警告が残っていました。
PHP Warning: PHP Startup: Unable to load dynamic library 'pdo_sqlite' (tried: /usr/lib64/php/modules/pdo_sqlite.so (/usr/lib64/php/modules/pdo_sqlite.so: undefined symbol: sqlite3_column_table_name)) in Unknown on line 0undefined symbol: sqlite3_column_table_nameというエラーは、pdo_sqlite.soが必要とするsqlite3の関数を見つけられないことを示しています。
原因の調査: lddコマンドでpdo_sqlite.soが依存している共有ライブラリを確認します。
$ ldd /usr/lib64/php/modules/pdo_sqlite.so
...
libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x00007fedb4c00000)
...結果、pdo_sqlite.soがシステムの標準ライブラリ（/usr/lib64/）ではなく、/usr/local/lib/にあるsqlite3ライブラリを参照していることが判明しました。これは、過去に手動でインストールしたsqliteが原因で、PHP が想定しているライブラリとの間に互換性の問題を引き起こしていました。
解決策: /usr/local/libにある競合するライブラリを、削除せずに名前を変更して無効化します。
$ sudo mv /usr/local/lib/libsqlite3.so.0 /usr/local/lib/libsqlite3.so.0.bakこの後、ldconfigコマンドでライブラリのキャッシュを更新します。
$ sudo ldconfig4. 最終確認
全ての警告が解消されたか、再度php -vで確認します。
$ php -v
PHP 8.3.19 (cli) (built: Mar 12 2025 13:10:27) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.3.19, Copyright (c) Zend Technologies
with Zend OPcache v8.3.19, Copyright (c), by Zend Technologiesクリーンな出力が得られ、無事にすべての問題が解決しました。
最後に、アップデート後の PHP パッケージ一覧を載せておきます。
$ dnf list installed | grep php
php.x86_64 8.3.19-1.module+el9.6.0+32042+808943ae @appstream
php-cli.x86_64 8.3.19-1.module+el9.6.0+32042+808943ae @appstream
... (省略) ...
php-xml.x86_64 8.3.19-1.module+el9.6.0+32042+808943ae @appstreamまとめ
PHP のバージョンアップは、単にdnf updateを実行するだけでは終わらないことがあります。特に、peclで拡張機能をインストールしている場合や、システムに手動でライブラリをインストールしている場合は、今回のように様々な依存関係の問題に直面することがあります。
トラブルシューティングで、細かい内部設定要因も書いておきました。通常発生することはないと思いますが、まぁこういうこともあると言うことで。
エラーメッセージを注意深く読み、lddのようなツールを使って原因を特定していくことが、問題解決の鍵となります。この記事が、同様の課題に直面した方の助けとなれば幸いです。
