Я запускаю сервер с nginx 1.12.2 и PHP 7.0.27 в Debian 8.10, у меня два веб-сайта с отдельными пулами PHP-FPM для каждого отдельного приложения PHP каждый сайт работает. Каждый пул PHP-FPM и, следовательно, каждое приложение PHP запускается под своим собственным пользователем с nginx, работающим как www-data.
Иногда (я думаю, что это периоды высокой нагрузки) я получаю от PHP всплески ошибок о проблемах чтения и записи файлы сеанса до разрешений, например: Сообщение PHP: Предупреждение PHP: Неизвестно: Не удалось записать данные сеанса (файлы). Убедитесь, что текущая настройка session.save_path верна (/ var / lib / php / sessions) в Неизвестном в строке 0 "при чтении восходящего потока, клиент: 34.242.193.225, сервер: example.org, запрос:" GET / somepage HTTP / 1.1 ", восходящий поток:" fastcgi: // unix: /run/php/php7.0-fpm-site-app.sock: ", host:" example.org "
Насколько я могу судить, разрешения верны, поскольку я вижу сеансы в папке от обоих пользователей PHP.
Если я запускаю ls -alF для имени файла, указанного в сообщении об ошибке, вскоре после его появления в файле журнала, файл будет там но принадлежат пользователю с другого сайта (с содержанием, которое предполагает, что это для сеанса с другого сайта), который предлагает мне, что оба приложения, работающие в разных доменах, сгенерировали один и тот же идентификатор сеанса, и одному удается успешно записать свой файл, а другому не удается, потому что файл существует, принадлежащий пользователю других сайтов. Насколько я понимаю, вероятность того, что оба сайта генерируют один и тот же идентификатор сеанса, практически невозможна.
Хотя я думаю, что могу решить симптомы, установив отдельные пути сеанса для каждого пула, я не думаю, что это решит основную проблему которые могут вызывать другие проблемы на сервере, которых я еще не заметил.
На самом деле это проблема программного обеспечения, а не nginx
или php-fpm
, и если вы используете одно и то же программное обеспечение в двух процессах, то это не произойдет. Не может быть невозможно вызвать столкновения. Беглый взгляд на документацию показывает, что, хотя обнаружение коллизий существует для одного приложения, два отдельных процесса в разных пользовательских пространствах этого не сделают. Самым простым решением было бы настроить session.save_path
по-разному для каждого пула.