WordPress本体のアップグレード中に、次のメッセージが表示されたままになりました。
現在メンテナンス中のため、しばらくの間ご利用いただけません。
5分ほど待っても画面が戻らず、更新が止まってしまったのではないかと思い、サーバーに接続して状況を確認しました。結果的には無事復旧できました。今回は、調査で分かったWordPressのメンテナンスモードの仕様と、ファイルの状態を調べるstatコマンドについて記録します。
この記事で扱うのは、WordPress標準の更新処理によるメンテナンス表示です。メンテナンス用プラグインやホスティング側の機能で表示されている画面は、解除方法が異なる場合があります。コマンド例はLinux環境を前提にしています。
⚠ 注意事項
設定内容やプログラムの内容は、用途・環境に応じて適切なものが変わります。
各種設定値や環境情報についてよく理解を深め、壊れてもよい環境で十分に検証してください。
なるべく正確に書くよう心掛けていますが、本投稿内容を実施される際には自己責任の下でお願いいたします。
まずはPHPのプロセスを確認
ps -ef | grep php表示されたのはPHP-FPMのマスタープロセスとワーカープロセスです。
PHP-FPMは通常のページ表示にも使われるため、プロセスが存在するだけでは、WordPressの更新が実行中かどうかは判断できませんが参考程度にはなります。
WordPressの設置フォルダにある .maintenance
今回のWordPress設置先は/var/www/html/wordpress/です。
次のコマンドで確認すると、.maintenanceがありました。
$ ls -alh /var/www/html/wordpress/.maintenance
-rw-r--r-- 1 www-data www-data 33 9月 20 00:54 /var/www/html/wordpress/.maintenanceWordPressは更新時にこのファイルを作成し、メンテナンス表示に使用するようです。
正常に処理が進めば削除されますが、更新の失敗などで残る場合があります。
ただし、更新中にも存在するファイルなので、あるだけで失敗したとは言えません。
メンテナンス判定には「10分」という条件がある
ファイルの中身を確認します。
$cat /var/www/html/wordpress/.maintenance
<?php $upgrading = 1789833247; ?>$upgradingには、メンテナンスモードを有効にした時刻がUNIXタイムスタンプで記録されています。
WordPress標準の処理では、この時刻から600秒、つまり10分以上経過すると、メンテナンスモードではないと判定します。
基準になるのはファイルの更新日時ではなく、ファイル内の$upgradingの値です。WordPress公式の実装
「10分経てば更新が必ず完了する」という意味ではありません。
また、この判定がファイル自体を削除するわけでもありません。メンテナンス表示の解除と、本体更新の成功は別々に確認する必要があります。
この判定はページへのリクエスト時に行われます。
10分後に開いている画面が自動で切り替わるわけではないため、再読み込みして確認します。
それでも表示が続く場合は、$upgradingの値が書き換わっていないか、キャッシュや別のメンテナンス機能が影響していないかも確認します。
DebianなどGNUのdateコマンドを使う環境では、記録された時刻を次のように変換できます。
TZ=Asia/Tokyo date -d @1789833247 '+%F %T %Z'タイムゾーンを日本時間に指定すると、次のように表示されます。
2026-09-20 00:54:07 JSTファイルの詳しい状態を調べる stat コマンド
今回初めて使ったのがstatコマンドです。ここではGNU版の出力を使います。ファイルのサイズ、所有者、権限、各種の時刻などをまとめて確認できます。GNU公式マニュアル
stat /var/www/html/wordpress/.maintenance実際の出力から、時刻の部分を抜粋します。
Access: 2026-09-20 00:54:09.109228692 +0900
Modify: 2026-09-20 00:54:07.341243162 +0900
Change: 2026-09-20 00:54:07.341243162 +0900
Birth: 2026-09-20 00:54:07.341243162 +0900| 項目 | 意味 |
|---|---|
| Access | ファイルの最終アクセス時刻。読み取りなどが対象 |
| Modify | ファイルの内容が最後に変更された時刻 |
| Change | 内容の書き換えや権限・所有者の変更など、ファイルの状態が最後に変更された時刻 |
| Birth | ファイルの作成時刻。取得できない環境では「-」になる |
Changeは作成時刻ではありません。例えばchmodで権限を変更すると、内容を書き換えなくてもChangeが変わります。またAccessは、ファイルシステムの設定によって読み取りのたびに更新されるとは限りません。GNU公式のタイムスタンプ解説
なお、出力にはAccess: (0644/-rw-r--r--)という行もあります。こちらはアクセス権限で、時刻のAccessとは別です。
時刻を整理すると、経過時間は5分27秒だった
現在時刻も確認しました。
TZ=Asia/Tokyo date '+%F %T %Z'2026-09-20 00:59:34 JST| 確認項目 | 時刻・時間 |
|---|---|
| .maintenance内の開始時刻 | 00:54:07 |
| ファイルの内容が変更された時刻 | 00:54:07 |
| 状況を確認した時刻 | 00:59:34 |
| 開始からの経過時間 | 5分27秒 |
| 開始から10分になる時刻 | 01:04:07 |
「ずっと戻らない」と感じていましたが、時刻を調べることで経過時間を具体的に把握できました。ただし、ファイルの更新日時が変わらないことだけでは処理が停止した証拠にはなりません。このファイルは、更新の進捗を逐次記録するログではないためです。
メンテナンス表示が続く場合の対応例
更新処理が失敗・終了しているにもかかわらず.maintenanceが残っている場合、WordPress公式ではファイルの削除を案内しています。WordPress公式の復旧手順
削除の代わりに、公開フォルダの外へ退避する方法もあります。次は対応例で、実行済みの操作記録ではありません。退避先の/path/to/private-backup/は、事前に用意した、Webからアクセスできない書き込み可能なディレクトリに置き換えてください。
mv -i /var/www/html/wordpress/.maintenance \
/path/to/private-backup/wordpress-maintenance-$(date +%Y%m%d-%H%M%S).txtこの操作は、更新画面の結果やPHP・Webサーバーのエラーログなどを確認し、更新処理が動いていないことを確かめてから行います。5分経ったことやPHP-FPMのプロセス一覧だけでは、停止したと判断できません。設置先も環境に合わせて変更してください。処理の状態を判断できない場合は、ホスティング事業者やサーバー管理者に確認します。
解除後はサイトと管理画面を開き、管理画面の「ダッシュボード → 更新」で更新状況を確認します。この記事の設置例では、管理画面のURLは/wordpress/wp-admin/です。データベースの更新を求められた場合は、案内に従って進めます。表示やログにエラーがないか、主要なページや機能も確認します。
更新が未完了なら、原因を確認してから再実行します。更新前にはファイルとデータベースをバックアップしておくことが基本です。障害発生後に保存したデータは、更新前の正常な状態に戻せるバックアップとは限らない点にも注意します。
今回の確認で分かったこと
最終的には復旧できましたが、ここで残しているのは途中の確認記録です。本記事では復旧時の具体的な操作まで示していないため、上の対応例を今回の復旧原因として断定することはできません。調査で学んだのは、メンテナンス表示だけでは更新の成否を判断できないことと、時刻を確認する大切さです。
次に同じ状態になったときは、まず.maintenanceの内容と現在時刻を確認し、statでファイルの状態も調べながら、落ち着いて対応したいと思います。