PHP7 in Ubuntu 16.04. One FPM pool try to chroot another FPM pool

abr_stackoverflow asked:

I move my sites from old PHP (php 5.4) and OS (Ubuntu 12.04) to new server with PHP 7 and Ubuntu 16.04. I cought bug with creating FPM pools. Here’s my common pool config:

[zabbix.example.com]
include = /etc/php/7.0/fpm/default-config.conf

user = www-data
group = www-data
listen = /data/www/zabbix/tmp/php-fpm.sock

request_terminate_timeout = 60s ; 30 sec for work
request_slowlog_timeout = 5s ; add to slowlog after 5 sec

slowlog = /data/www/zabbix/logs/slow.log
chroot =  /data/www/zabbix
chdir =   /public_html

php_admin_flag[display_errors] = off
php_admin_flag[display_startup_errors] = off

php_admin_value[memory_limit] = 256M
php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -fno_reply@example.com

php_admin_value[post_max_size] = 16M
php_admin_value[max_execution_time] = 300
php_admin_value[max_input_time] = 300

Here’s default-config.conf:

pm = dynamic
pm.max_children = 100
pm.start_servers = 12
pm.min_spare_servers = 5
pm.max_spare_servers = 50
pm.max_requests = 1000
pm.status_path = /status

listen.backlog = -1
listen.owner = www-data
listen.group = www-data
listen.mode = 0666

ping.path = /ping
ping.response = pong

request_terminate_timeout = 90
request_slowlog_timeout = 20
catch_workers_output = yes
php_flag[display_errors] = off
php_flag[display_startup_errors] = off
php_value[disable_functions] = show_source,system,shell_exec,passthru,exec,popen,proc_open

php_admin_value[upload_tmp_dir] = /tmp

security.limit_extensions = .php .php3 .php4 .php5 .htm

This config works at the old server. But at the new server I have problem with chrooting. Some sites use another site chroot directories. For example, I have these pools: site1.example.com, site2.example.com, site3.example.com, zabbix.example.com. So site1.example.com tries to look to site2.example.com directory. If I load site3.example.com it shows me zabbix.example.com.

How I can fix it?

My answer:


This is a known bug in PHP, which unfortunately has been around for years without a fix.

However, there is a workaround available: Setting

opcache.revalidate_freq=0

in php.ini (or a file included from it) works around the problem at a slight performance penalty, though far less of a penalty than turning off opcache.


View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.