私は Debian 8.10 で nginx 1.12.2 と PHP 7.0.27 を搭載したサーバーを実行しており、各サイトで実行される個別の PHP アプリケーションごとに個別の PHP-FPM プールを持つ 2 つの Web サイトを実行しています。各 PHP-FPM プール、つまり各 PHP アプリケーションは独自のユーザーで実行され、nginx は www-data として実行されます。
時々 (おそらく負荷が高いとき)、セッション ファイルの読み取りと書き込みから権限に至るまでの問題に関する PHP からのエラーが大量に発生します。たとえば、次のようになります。
2018/02/21 02:07:19 [error] 11723#11723: *804992 FastCGI sent in stderr: "PHP message: PHP Warning: Unknown: open(/var/lib/php/sessions/sess_<session id here>, O_RDWR) failed: Permission denied (13) in Unknown on line 0 PHP message: PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/sessions) in Unknown on line 0" while reading upstream, client: 34.242.193.225, server: example.org, request: "GET /somepage HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm-site-app.sock:", host: "example.org"
私の知る限り、両方の PHP ユーザーからのセッションがフォルダー内に表示されているので、権限は正しいです。
ログ ファイルに表示された直後に、エラー メッセージで指定されたファイル名で ls -alF を実行すると、ファイルは存在しますが、他のサイトのユーザーが所有しています (他のサイトのセッション用であることを示唆する内容を含む)。これは、別のドメインで実行されている両方のアプリが同じセッション ID を生成し、1 つはファイルの書き込みに成功し、もう 1 つはファイルが他のサイトのユーザーの所有であるため失敗したことを示しています。私の理解では、両方のサイトが同じセッション ID を生成する可能性はほとんどないはずです。
各プールに個別のセッション パスを設定することで症状は解決できると思いますが、サーバー上でまだ気付いていない他の問題を引き起こしている可能性のある根本的な問題はこれでは解決されないと思います。
答え1
これは実際にはソフトウェアの問題であり、nginxまたは ではありませphp-fpmん。同じソフトウェアを 2 つのプロセスで実行している場合は、衝突が発生する可能性がゼロではありません。ドキュメントをざっと見ると、単一のアプリケーションには衝突検出機能がありますが、異なるユーザー空間にある 2 つの別個のプロセスでは衝突検出機能がないことがわかります。最も簡単な修正方法は、session.save_pathプールごとに異なる構成にすることです。