0

I'm running a server with nginx 1.12.2 and PHP 7.0.27 on Debian 8.10, I'm running two websites with separate PHP-FPM pools for each separate PHP application each site runs. Each PHP-FPM pool and thus each PHP app runs under its own user with nginx running as www-data.

At times (I think its times of high load) I get bursts of errors from PHP about issues reading and writing the session files down to permissions, for example:

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"

As far as I can tell the permissions are correct as I'm seeing sessions in the folder from both PHP users.

If I run an ls -alF on the file name given in the error message shortly after it shows up in the log file the file will be there but owned by the user from the other site (with contents that suggest it is for a session from the other site), which suggests to me both apps running on separate domains have generated the same session ID and one manages to successfully write its file, and the other fails because the file exists owned by the other sites user. As I understand it the chances both sites generating the same session ID should be pretty much impossible.

Whilst I think I can solve the symptoms by setting separate session paths for each pool, I don't think this would solve the underlying problem which might be causing other issues on the server I've yet to notice.

Technofrood
  • 23
  • 1
  • 8

1 Answers1

0

This is actually a software issue, not nginx or php-fpm, and if you are running the same software in two processes then it wouldn't be impossible to cause collisions. A quick look at the documentation suggests that while there is collision detection for a single application, two separate processes in different userspaces wouldn't do this. The simplest fix would be to configure session.save_path differently for each pool.

Simon Greenwood
  • 1,363
  • 9
  • 12
  • I would say this is an issue with PHP-FPM and the way it generates session IDs in the first place. This can be easily avoided with the per-pool path setting you mentioned. – Tero Kilkanen Feb 21 '18 at 23:33