HTTPエラー503。サービスを利用できません：ホスティングサポートのケース

ホスティングサポートの作業は基本的に同じタイプであり、クライアントからのリクエストのほとんどは十分に開発されたスキームに従って解決されますが、それでも重要な問題に直面することがあります。次に、エンジニアの主なタスクは、1つを見つけることです。その解決につながる唯一の正しいパスです。この記事では、共有ホスティングでフローティングエラー「HTTPエラー503。サービスを利用できません」が発生した方法、それを検出しようとした方法、診断方法、予期しない終了結果について説明します。

開始

ホスティングは、典型的なLinux + Apache + Mysql + PHPスタックと管理ラッパーをユーザーに提供します。私たちの場合、これはCloudLinuxに変換されたCentos 7に基づくISP Manager 5ビジネスです。 CloudLinuxは、管理側から、制限を管理するためのツールと、さまざまな操作モード（CGI、FastCGI、LSAPI）を備えたPHPセレクターを提供します。



今回、クライアントから以下の問題がありました。 Wordpressエンジン上の彼のサイトは定期的に503エラーを出し始めました。



50xで始まる応答コードは、サーバー側の問題を参照しています。これらは、サイト自体とそれらを提供するWebサーバーの両方の問題である可能性があります。



次のエラーが表示される一般的な状況：

• 500内部サーバーエラー-多くの場合、サイトコードの構文エラーか、ライブラリが見つからないか、サポートされていないPHPバージョンです。また、サイトデータベースへの接続に問題があるか、ファイル/ディレクトリの不正な権限がある可能性があります
• 502不正なゲートウェイ-たとえば、Nginxが間違ったApacheウェブサーバーポートを参照している場合、またはApacheプロセスが何らかの理由で動作を停止した場合
• 504ゲートウェイタイムアウト-Apacheからの応答がWebサーバー構成で指定された時間内に受信されませんでした
• 508リソース制限に達しました-ユーザーに割り当てられたリソースの制限を超えました

このリストには、最も一般的なケースの一部のみが含まれています。また、制限を超えると、ユーザーは500エラーと503エラーの両方を受け取る可能性があることにも注意してください。



これらのエラーを診断する場合、最初のステップはWebサーバーのログを確認することです。これは通常、原因を特定して問題を解決するのに十分です。



この場合の503エラーに関しては、ログにエントリが表示されました。

[lsapi：エラー] [pid 49817] [クライアントxxxx：6801] [ホストXXX.XX]リクエスト送信時のエラー（GET /index.php HTTP / 1.0）; uri（/index.php）content-length（0）：ReceiveAckHdr：バックエンドから読み取るものは何もありません（LVE ID 8514）。docs.cloudlinux.com/ mod_lsapi_troubleshooting.htmlを確認してください

このログのみに基づいて、問題が何であるかを判別することはできませんでした。

一次診断

最初に、制限を超えるユーザーの統計をチェックしました。前日のわずかな超過が記録されましたが、ログのエラーは新鮮で、さらに、1〜数分間隔でログに表示されました。



エラーログで提供されるリンクを使用して、CloudLinuxの推奨事項についても調査しました。

パラメータを変更しても結果は得られませんでした。



サイトは、Dockerコンテナー内の同じサーバー上で実行されるMysql 5.7サーバー上のデータベースを使用しました。コンテナログに含まれるメッセージ：

[Note] Aborted connection 555 to db: 'dbname' user: 'username' host: 'x.x.x.x' (Got an error reading communication packets)

これらのメッセージの中には、調査中のサイトの接続の中断に関するメッセージが含まれていました。これは、DBMSへの接続が正しく実行されていないことを前提としています。これを確認するために、サイトのコピーをテストドメインに展開し、サイトデータベースを5.5.65-MariaDB DBMSのネイティブCentos 7バージョンに変換しました。テストサイトでは、curlユーティリティを使用して数百のリクエストが実行されました。エラーを再現できませんでした。しかし、この結果は暫定的なものであり、本番サイトでデータベースを変換した後も問題は残りました。



したがって、DBMSへの誤った接続の問題が解消されました。



次の提案は、サイト自体に問題があるかどうかを確認することでした。これを行うには、別の仮想サーバーをセットアップし、その上で最も類似した環境を作成しました。唯一の大きな違いは、CloudLinuxがないことです。テストサーバーで問題を再現できませんでした。したがって、サイトコードではすべてが正しいと判断しました。ただし、同じ方法でWordpressプラグインを無効にしようとしましたが、問題は解決しませんでした。



その結果、問題はホスティングにあるという結論に達しました。



他のサイトのログを分析した後、問題がそれらの多くで観察されていることがわかりました。約100個検証時：

/var/www/httpd-logs# grep -Rl "ReceiveAckHdr: nothing to read from backend" ./ | wc -l
99

テスト中に、新しくインストールされたクリーンなCMS Wordpressでも定期的にエラー503が発生することがわかりました。



その約2か月前に、サーバーの近代化に関する作業を実行しました。特に、PHPを使用できるように、Apacheの動作モードをWorkerからPreforkに変更しました。遅いCGIではなくLSAPI。これが影響する可能性がある、または追加のApache設定が必要であるという想定がありましたが、ワーカーモードを戻すことができませんでした。 Apache動作モードの変更中に、すべてのサイト構成が変更されます。プロセスは高速ではなく、すべてがスムーズに進むとは限りません。



Apache設定を修正しても、望ましい結果が得られませんでした。



その過程で、検索エンジンで同様の問題を探しました。フォーラムの1つで、参加者はホスティング業者に問題があり、問題が解決しない場合は変更する必要があると主張しました。反対側にいるときは楽観的に聞こえませんが、クライアントは理解できます。なぜ彼は非稼働ホスティングを必要とするのですか？



この段階で、利用可能な情報と実行された作業の結果を収集しました。CloudLinuxをサポートするために彼らに連絡しました。

詳細な診断

数日間、CloudLinuxサポートスタッフがこの問題を詳しく調査しました。基本的に、推奨事項は確立されたユーザー制限に関するものでした。この質問もチェックしました。制限を無効にして（ユーザーのCageFSオプション）、ApacheモジュールとしてPHPモードで制限を有効にすると、問題は観察されませんでした。これに基づいて、CloudLinuxが何らかの形で影響していることが示唆されています。その結果、週の終わりまでにリクエストは第3レベルのサポートにエスカレートされましたが、まだ解決策はありませんでした。



その過程で、CGIおよびLSAPIモードに関するApacheのドキュメントを調査し、ホスティングサーバーのテストサイトのある別のポートに2つ目のApacheインスタンスをセットアップし、Apacheにリクエストを直接送信して同じエラーコードを受信することにより、Nginxの影響を排除しました。



：LSAPIのドキュメントは、ちょうど503エラーの診断に、地面をオフに取得するために助けた

www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki：PHP：503-エラー

高度なトラブルシューティングのセクションでは、プロセスをトレースすることが提案されているシステムで見つかりました：

while true; do if mypid=`ps aux | grep $USERNAME | grep lsphp | grep $SCRIPTNAME | grep -v grep | awk '{print $2; }' | tail -1`; then strace -tt -T -f -p $mypid; fi ; done

このコマンドは、すべてのプロセスをその識別子とともにファイルに記録するように改良されました。



トレースファイルを見ると、同じ行がいくつか表示されます。

cat trace.* | tail
...
47307 21:33:04.137893 --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=42053, si_uid=0} ---
47307 21:33:04.140728 +++ killed by SIGHUP +++
...

プロセスによって送信されたシグナルの構造の説明を見ると、

pid_t    si_pid;       /* Sending process ID */

シグナルを送信したプロセスの識別子を示します。



トレースを調査した時点では、PID 42053のプロセスはシステムに存在しないため、トレースをキャプチャするプロセスでは、SIGHUP信号を送信したプロセスも監視することにしました。

スポイラーの下で、それがどのようなプロセスであるかを判別し、そのトレースと、SIGHUPシグナルを送信するプロセスに関する追加情報を取得できるようにするアクションが説明されています。





その結果、プロセスの名前がわかり、/opt/alt/python37/bin/python3.7 -sbb /usr/sbin/cagefsctl --rebuild-alt-php-ini



このプロセスはシステムで1分に1回実行されました。



いくつかのcagefsctlプロセスをトレースして、最初から最後まで少なくとも1つをトレースします。

for i in `seq 1 100`; do strace -p $(ps ax | grep cagefsctl | grep rebuild-alt-php-ini | grep -v grep | awk '{print $1}') -o /tmp/strace/cagefsctl.trace.$(date +%s); done;

次に、私たちは彼が何をしたかを調べます、例えば：

cat /tmp/strace/cagefsctl.trace.1593197892 | grep SIGHUP

SIGHUPシグナルで終了したプロセスIDも取得されました。終了したプロセスは、現在実行中のPHPプロセスです。



受信したデータは、このプロセスの正当性と、そのような頻度で動作するかどうかを明確にするために、CloudLinuxサポートに転送されました。



その後、チームの作業/usr/sbin/cagefsctl --rebuild-alt-php-iniが正しく行われているという回答を受け取りましたが、唯一の注意点は、チームが頻繁に実行されていることです。通常、システムアップデートまたはPHP設定が変更されたときに呼び出されます。



この場合の唯一の手掛かりは、cagefsctlプロセスの親が誰であるかを確認することです。



結果は間もなくで、私たちが驚いたことは何ですか。cagefsctlの親プロセスはispmgrnodeプロセスでした。ISPマネージャーのログレベルが最大に設定されていて、caspfsctl呼び出しがispmgr.logに表示されていなかったため、少し奇妙でした。



これで、ISPシステムサポートに連絡するのに十分なデータが揃いました。

概要

この問題は、ISPマネージャーのアップデートを実行した後にトリガーされました。一般に、ISPマネージャーの更新は通常の状況ですが、同期プロセスが開始され、エラーで終了し、毎分再起動されました。同期プロセスにより、Cagefsctlプロセスが呼び出され、PHPプロセスが終了しました。



同期プロセスのハングアップの理由は、機器を最新化するためにホスティングで実行された作業でした。問題が発生する数か月前に、PCI-e NVMeドライブがサーバーにインストールされ、XFSパーティションが作成され、/ varディレクトリにマウントされました。ユーザーのファイルもそこに転送されましたが、ディスククォータは更新されませんでした。マウントオプションは十分ではなく、ISP Managerパラメータのファイルシステムタイプを変更する必要もありました。コマンドを呼び出してディスククォータを更新します。Ext4とXFSの場合、これらのコマンドは異なります。



したがって、問題は作業の数か月後に感じられました。

結論

私たち自身が問題を作成しましたが、最後の瞬間まで明確ではありませんでした。将来的には、できるだけ多くのニュアンスを考慮に入れるよう努めます。CloudLinuxとISPシステムサポートからトレーニングを受けた同僚の助けを借りて、問題は解決しました。現在、ホスティングは安定しています。そして、私たちは将来の仕事に役立つであろう経験を積んでいます。



PS：私はあなたが記事を読むことに興味を持っていれば幸いです、そしてそれが誰かが同様の問題を素早く解決するのを助けるでしょう。