Потенциальная коллизия идентификаторов сеансов отдельных пулов PHP-FPM

Потенциальная коллизия идентификаторов сеансов отдельных пулов PHP-FPM

Я запускаю сервер с nginx 1.12.2 и PHP 7.0.27 на Debian 8.10, я запускаю два веб-сайта с отдельными пулами PHP-FPM для каждого отдельного приложения PHP, которое запускает каждый сайт. Каждый пул 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 для имени файла, указанного в сообщении об ошибке, вскоре после того, как оно появится в файле журнала, файл будет там, но его владельцем будет пользователь с другого сайта (с содержимым, которое предполагает, что это сеанс с другого сайта), что говорит мне о том, что оба приложения, работающие на разных доменах, сгенерировали один и тот же идентификатор сеанса, и одно из них успешно записывает свой файл, а другое терпит неудачу, потому что файл существует и принадлежит пользователю другого сайта. Насколько я понимаю, вероятность того, что оба сайта сгенерируют один и тот же идентификатор сеанса, должна быть практически нулевой.

Хотя я думаю, что могу решить симптомы, установив отдельные пути сеансов для каждого пула, я не думаю, что это решит основную проблему, которая может вызывать другие проблемы на сервере, которые я еще не заметил.

решение1

На самом деле это проблема программного обеспечения, а не nginxили php-fpm, и если вы запускаете одно и то же программное обеспечение в двух процессах, то не исключено, что возникнут коллизии. Беглый взгляд на документацию показывает, что хотя для одного приложения есть обнаружение коллизий, два отдельных процесса в разных пользовательских пространствах этого не сделают. Самым простым решением будет настроить session.save_pathпо-разному для каждого пула.

Связанный контент