Linux PHP Wordpress

WordPressの更新が失敗する。タイムアウト「 upstream timed out (110: Connection timed out)」が原因であることをNginxのログから特定し、タイムアウトを延長することで解決した話。

コトの発端

WordPressの更新の案内が管理画面に来ていた。

WordPress本体の自動更新は設定していたが、不思議に思いながら更新ボタンをクリックした。しかし、しばらくすると。。。

すごく、真っ白です。

ページのアドレスバーに

(サイトドメイン)/wp-admin/update-core.php?action=do-core-upgrade 

の表示があるだけの、空白のページが表示された。

管理画面で確認するも更新はされていない様子だった。困った。

今回の環境

Conoha VPSで構築したWordPress(KUSANAGI)環境。KUSANAGIはCentOSベースの仮想マシン。

Nginx + PHP7.4 環境

常時SSL接続

原因調査 序章

こういうエラーの原因って特定が難しいよね。パターンが多すぎる。

まずは構築時の心当たりをたどってみる。

そういえばプラグイン「JetPack」導入時にタイムアウトが発生して通常の方法で導入できなかったことがあったけど、現象としてはそれに近いか。。。?

※ちなみにこの現象は解凍したJetPackプラグインのファイルをSCPでアップロードするという力業で解決した。

まぁ結局のところ、何らかの条件で「こちら側の環境に起因するタイムアウト」が発生しやすい環境ということしか手がかりがないわけか。

原因調査

とにもかくにもログ調査。

エラーログとかの場所は前項の環境だと下記の場所になるはず。一般的な言い方をするとWEBサーバのログの出力場所。

cd /home/kusanagi/unluckysystems/log/nginx

なんかログファイルがいっぱい。直近のエラーは下記のファイルに出力されているっぽい。ほかのファイルは過去ログとかになるのかな。

vim ssl_error.log

エラーが発生した日時に記録されていたログは下記の通り。

2021/08/07 17:49:43 [error] 1029#0: *83010 upstream timed out (110: Connection timed out) while reading upstream, client: (管理画面にアクセスしたIP), server: unluckysystems.com, request: "POST /wp-admin/update-core.php?action=do-core-upgrade HTTP/2.0", upstream: "fastcgi://127.0.0.1:9000", host: "unluckysystems.com", referrer: "https://unluckysystems.com/wp-admin/update-core.php"

upstream timed out (110: Connection timed out) ってなってるし、原因としてはタイムアウトということで良さそう。

解決編

JetPackプラグイン導入中に 504 Gateway Time-out 504 Gateway Time-out が出ていたことを思い出し、その解決方法を調べていたら下記のサイトにたどり着いた。

https://qiita.com/kinokosan/items/3aadb0bdfc6e2ae6de36

上記サイトを一部参考にNginxの設定を変更することにした。

設定ファイルはワイの環境だと下記の場所にこの名前で存在した。

vim /etc/nginx/conf.d/unluckysystems_ssl.conf

/wp-admin/*のセクションに下記の行を修正し、タイムアウトを延長した

fastcgi_read_timeout 600s;

ワイの環境では、デフォルトだと104行目に設定項目があったと思う。

設定ファイルを変更後、下記コマンドでnginxサービスを再起動して設定を反映させた。

systemctl restart nginx

その後、管理画面で「今すぐ更新」をクリックすると、数分の後に更新が完了した。

さっき紹介したサイトだと、他のタイムアウト値もいじってたけど、今回のパターンの場合+ワイの環境ではfastcgi_read_timeoutの値を変更するだけで更新が成功した。

めでたしめでたし。

ただし、この設定が決め手になって更新が成功したものの、いろんな設定を試していたことから紹介しきれなかった要素も影響しているかもしれない。ご参考までに。

一応、おまけとして実験したものの一部を乗せておきます。

おまけ 今回は関係してなかった(と思う)設定項目

実験した記録を乗せてみる。

ファイアウォール(これはマジで関係なかった)

下記は外部からのアクセスを受け付けるためのファイアウォールの導入時の設定。(もちろん他にSSH用のポートもあるよ。)

firewall-cmd --zone=public --permanent --add-service=https
firewall-cmd --zone=public --permanent --add-service=http

下記はファイアウォールのポート番号9000番(TCP)をポート開放したコマンド(suでrootに昇格せずsudoでいいかもね)

su
firewall-cmd --zone=public --permanent --add-port=9000/tcp
firewall-cmd --reload

下記コマンドで確認

firewall-cmd --list-all

php-fpmの実行タイムアウト値の設定(これは関係ありそう。今回たまたま設定値がアップデート時間内だっただけかも。)

設定ファイル

vim /etc/php7-fpm.d/www.conf

設定内容(ワイの環境のデフォルト値だったと思う。必要に応じて延長すべし。)

request_terminate_timeout = 180

php-fpm設定の参考にしたページ

nginxのタイムアウトエラー(upstream timed out(110 : Connection timed out) while reading response header from upstream))

https://urashita.com/archives/1530

いつもの

記事の正確性については無保証です。

他のおすすめ記事

  • この記事を書いた人
あっきー

あっきー

とある企業の研究者。研究分野以外に手を出しすぎて毎日が慌ただしい。 研究者の肩書きが正しいかどうかは万年の謎。 得意ジャンルはデータベースとセキュリティーですが、AIやIoT、アプリ開発など、手広く活動しています。

-Linux, PHP, Wordpress
-, ,

Translate »