web-dev-qa-db-ja.com

PHP-FPM + nginxによる権限の生成は拒否されましたが、特定の大きなページでのみ

AWS Lightsailインスタンス（1GB RAMインスタンス）で比較的新しいウェブサイトを実行しています（つまり、実質的にトラフィックがありません）。それはnginxとPHP-FPM 7.3（7.2でも試してみました）とMariaDBを実行しています。これはすべてCentOS 7の下にあります。

AWSの無料枠ではすべてが問題なく機能しました。 T2.micro EC2インスタンスとT2.micro RDSインスタンスを実行しました。 Lightsailは少し...タッチしました。 Lightsailを機能させるために、PHP-FPMをondemandに切り替えました

ondemand-起動時に子は作成されません。新しいリクエストが接続されると、子供は分岐します。

これを行わないと、MariaDBがランダムにクラッシュしました。これは以下の問題には影響しないようです。

Wordpress管理パネルが正常に機能しなくなり、誰もがCONCATENATE_SCRIPTSをオフにするように言われました。これはほとんど機能します...投稿とテンプレートの両方のエディターが誤動作します。誰もなぜなのか、私には手掛かりがありました。

機能していないページが完全に読み込まれていません。 CONCATENATE_SCRIPTSをオンにすると、CSSファイルが1つの巨大なページに読み込まれます。これは完全にレンダリングに失敗するため、CSSおよびJSファイルはブラウザーによって無視されます。 CONCATENATE_SCRIPTSは、サイズが小さくロードが簡単なコンポーネントファイルに分割するだけで、この問題を回避します。しかし、編集ページを分割することはできず、根本的な問題のデバッグは厄介です。 200応答といくつかのデータを取得します

Page returns 200

しかし、ページの描画は不完全です。 HTMLの80〜90％はあると思いますが、切り捨てられています。ここから始まるセクション（JSブロック）

wp.apiFetch.use( wp.apiFetch.createPreloadingMiddleware( {"\/":{"body":{"name":"S

突然終了し、毎回同じ時点で終了します。これは、PHP-FPMまたはnginxが停止した直後のようですが、エラーログはありません（このタイプの設定に関する他の問題のほとんどは、ページがまったく描画されないためです）。さらに奇妙なことに、それは小さなページではなく、本当に長いページに対してのみ行われます。 topにはスチールタイムがなく、インスタンスには深刻な負荷がかかっていないようです。そのため、なぜそうなるのかはわかりません。私はすべてのファイルを新たにリロードし、別のWPこれをテストするためのサイトをセットアップし、すべてがそれを実行しました。

コメントごとに、nginxデバッグログをオンにして見つけました

2019/08/07 02:33:08 [crit] 1461#0: *47 open() "/var/lib/nginx/tmp/fastcgi/3/00/0000000003" failed (13: Permission denied) while reading upstream, client: x.x.x.x, server: example.com, request: "GET /wp-admin/post-new.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000",

これは、ほんの一握りの大きなファイルでこれを実行する理由には意味がありません。ドライブがいっぱいか、それに近いドライブはありません。私は この質問 を読みましたが、nginxとPHP-FPMの両方がApacheの下で実行されています。 tmpファイルを削除しても修正されませんでした。ディレクトリはApache:rootが所有していますが、Apache:apacheに変更しても効果はありません。 SELinuxも原因ではないようです。また、proxy_cacheも使用していません。

nginxphpphp-fpmwordpressamazon-lightsail
2
Machavity

まず、失敗はプロキシキャッシュではなくFastCGIバッファリングに関連しています。

これは/var/lib/nginx/tmp/fastcgi...から明らかです。

特に大きなページでのみエラーが発生する理由：構成されたFastCGIバッファーがPHP-FPMからの応答全体をメモリに収めるのに十分でない場合もちろん、これは大きな応答でより頻繁に発生します、 NGINXは一時ファイルへの応答の一部を書き込もうとします。

そして、どうやら、FastCGI一時ファイルを保持するためのディレクトリのアクセス許可では、NGINXがそこにファイルを保存できないため、応答が「大きすぎる」特定の時点で正確に失敗します。

パス/var/lib/nginx/tmp/fastcgiは、公式のNGINXディストリビューションを使用していないことも示しています。使用した場合、最終的には/var/cache/nginx/fastcgi_tempが所有するnginx:rootとなるためです。

ストックの公式NGINXディストリビューションを使用することをお勧めします。

nginxとPHP-FPMの両方がApacheの下で実行されています

トピック外ですが、これはとにかく間違った設定です。正しい設定では、NGINXを1人のユーザー（Apache、nginxなど）として実行していますが、アプリケーションのPHP-FPMプールは、独自のユーザー（例： foo。次に、nginxユーザーメンバーをfooグループのメンバーにします。特定のサーバーにアプリが1つしかないからといって、すべてを1人のユーザーで実行することには言い訳はありません。

いずれにせよ、それを一般的なchmod問題のように扱います。

  • NGINXワーカープロセスで実行するユーザーを確認します（構成内のuserディレクティブ）
  • 問題のディレクトリのファイルを、そのユーザーを上から下に使用して、動作が停止する場所が見つかるまでリストし、権限を再帰的に修正してください。

たとえば、NGINXワーカープロセスが実際にApacheユーザーによって実行されており、/var/lib/nginx/tmp/fastcgiにアクセスできないとしましょう。

Sudo -u Apache ls /var/

これはうまくいきましたか？権限は問題ありません。NGINXワーカープロセスのユーザーを介してこのディレクトリに移動できます。下位のディレクトリの内容を読み取るには、上位のすべてのディレクトリを（rxアクセス権のように）トラバースできる必要があることを理解することが重要です。つまり、「最終目的地」である/var/lib/nginx/tmp/fastcgiの場合、/var、/var/libなどをすべて読み取ることができる必要があります。

/varを読み取っても機能しない場合（システムの破損を示している可能性があります）、「他の人」に読み取らせる必要があります。 chmod o+rX /var

Sudo -u Apache ls /var/lib

これは機能しますか？/var/libの権限は問題ありません。そうでない場合は、他の人に読んでもらう必要があります：chmod o+rX /var/lib

Sudo -u Apache ls /var/lib/nginx

これは機能しますか？そうでない場合は、statを使用して所有権と権限の両方を確認してください。次に、NGINXユーザーがディレクトリ/var/lib/nginxの所有者であり、chmod（今回は「所有者」）がディレクトリに移動できることを確認します。

chown Apache:root /var/lib/nginx
chmod u+rX /var/lib/nginx

/var/lib/nginx/tmpについて、同じ（NGINXのユーザーが所有し、それを読み取る（トラバースする）ことができる）ことを確認します。

最後に、/var/lib/nginx/tmp/fastcgiの場合、NGINXユーザーが読み取り、実行（トラバース）、および書き込みのすべてを実行できる必要があります。

chown Apache:root /var/lib/nginx/tmp/fastcgi 
chmod 0700 /var/lib/nginx/tmp/fastcgi

つまり、基本的にはすすぎであり、機能するまで関連ファイルに移動しながら操作を繰り返します。

ディレクトリの内容を一覧表示し、その中にファイルを作成して、すべてが正しく設定されていることを確認します。

Sudo -u Apache ls /var/lib/nginx/tmp/fastcgi
Sudo -u Apache touch /var/lib/nginx/tmp/fastcgi/test.txt
5
Danila Vershinin