There is a machine with nginx and php-fpm on it. There are 2 servers, 2 php-fpm pools (each one with chroot) and 2 directories that has the same structure and similiar files/php classes.
One pool is listening on 127.0.0.1:22333 while another on 127.0.0.1:22335.
The problem is when I make a request to the second server it is somehow executed on the first pool. More strange that sometimes it takes some PHP classes from one directory (of the first pool), sometimes from another. There is not a specific pattern, it seems that it happens randomly.
e.g: Nginx logs show that request comes to the second server and php-fpm logs shows that is was handled in the first pool.
But it never happens other way around (requests to the first server are always executed with first php-fpm pool)
Pools are set up in the same way:
same user
same group
pm = dynamic
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30
pm.max_requests = 300
chroot = ...
chdir = /
php_flag[display_errors] = on
php_admin_value[error_log] = /logs/error.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 64M
catch_workers_output = yes
php_admin_value[upload_tmp_dir] = ...
php_admin_value[curl.cainfo] = ...
Nginx servers directive for php looks like:
fastcgi_pass 127.0.0.1:2233X;
fastcgi_index index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param DOCUMENT_ROOT /;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_intercept_errors off;
Had the same problem.
Best answer on this so far was on ServerFault which suggested opcache.enable=0, which pointed me to an quite interesting behavior of PHP.
the APC/OPcache cache is shared between all PHP-FPM pools
Digging further through opcache documentation I found this php.ini option:
opcache.validate_root=1
opcache.validate_root boolean
Prevents name collisions in chroot'ed environments. This should be enabled in all chroot'ed environments to prevent access to files outside the chroot.
Setting this option to 1 (default is 0) and restarting php-fpm fixed the problem for me.
EDIT:
Searching for the right words (validate_root) I found much more on this bug:
https://bugs.php.net/bug.php?id=69090
https://serverfault.com/a/877508/268837
Following the notes from the bug discussion, you should also consider setting opcache.validate_permission=1
After hours of searching and debugging I give up!
There are thousands of questions and articles about long running PHP processes but non of them solved my issue.
I have a PHP script with the following codes:
$cur = 0;
// Second, loop for $timeout seconds checking if process is running
while( $cur < 31 ) {
sleep(1);
$cur += 1;
echo "\n ---- $cur ------ \n";
}
It is simply intended to run for 31 seconds.
I have a Nginx, PHP configured as fastcgi in debian server.
I set
max_execution_time = 600
In
/etc/php5/fpm/php.ini
I even set it in
/etc/php5/cli/php.ini
Also set
request_terminate_timeout = 600
in
/etc/php5/fpm/pool.d/www.conf
I also made these changes in nginx.conf http section
client_header_timeout 600;
client_body_timeout 600;
send_timeout 600;
fastcgi_read_timeout 600;
fastcgi_send_timeout 600;
client_max_body_size 600;
fastcgi_buffers 8 128k;
fastcgi_buffer_size 128k;
And put the directives inside server section. and these directives inside location section of nginx configuration
send_timeout 600;
fastcgi_read_timeout 600;
fastcgi_send_timeout 600;
client_max_body_size 600;
fastcgi_buffers 8 128k;
fastcgi_buffer_size 128k;
But I still encounter the Gateway Timeout error in the browser!
(And Yes! I restarted php-fpm and nginx thousands of times)
Do you guys have any idea?
Please don't take my answer as an insult but, did you make sure that your web server is on and did you try accessing another page of the site?
After seeing this answer, I tend to believe the situation is a s follows: nginx is trying to fill its FastCGI buffer (which is enabled by default) while your script is taking too long to return the first byte, resulting into the timeout. Provided I am correct, there are two things you need to do in order to resolve this:
Switch fastcgi_buffering to off
alter your script so that flush() and ob_flush() are called after each iteration:
while( $cur < 31 ) {
++$cur;
echo "\n ---- $cur ------ \n";
flush();
ob_flush();
sleep(1);
}
hth
I believe that you need to include the proxy_read_timeout directive in your Nginx configuration file. My own configuration file looks like this:
server {
proxy_read_timeout 300s;
...
}
You'll note that that is in my server block, however this directive is also valid inside of the http and location blocks as well.
*Edit to add that this is because Nginx proxies requests to the PHP-FPM server; the directives you attempted to use are only valid for content that is being served by Nginx itself, and not being proxied.
I'm trying to take advantage of nginx upstream using socket but receiving errors in my log:
connect() to unix:/var/run/user_fpm2.sock failed (2: No such file or directory) while connecting to upstream
I might be going about this wrong and looking for some advice/input.
Here's the nginx conf block:
upstream backend {
server unix:/var/run/user_fpm1.sock;
server unix:/var/run/user_fpm2.sock;
server unix:/var/run/user_fpm3.sock;
}
And:
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_pass backend;
fastcgi_index index.php;
include fastcgi_params;
}
Then, I have 3 PHP pools at /etc/php/7.0/fpm/pool.d/ that look pretty much the same as below. The only difference between the pools is _fpm1, _fpm2, and _fpm3 to match the upstream block.
[user]
listen = /var/run/user_fpm1.sock
listen.owner = user
listen.group = user
listen.mode = 0660
user = user
group = user
pm = ondemand
pm.max_children = 200
pm.process_idle_timeout = 30s
pm.max_requests = 500
request_terminate_timeout = 120s
chdir = /
php_admin_value[session.save_path] = "/home/user/_sessions"
php_admin_value[open_basedir] = "/home/user:/usr/share/pear:/usr/share/php:/tmp:/usr/local/lib/php"
I've noticed the /var/run always ONLY has the user_fpm3.sock file.
Am I going about this wrong? Is it possible to make this upstream config work? All advice and critique welcome.
I'm running PHP7 on Debian Jessie with nginx 1.10.3 - Server has 6 CPU's and 12GB RAM.
Thanks in advance.
UPDATE: I figured the answer myself, but leaving the question in case someone else is trying to do the same thing, or there's a way to optimize this further.
All I had to do was change my pool names to [user_one], [user_two], and [user_three]
Changing the the name of each PHP pool fixed the problem, like so:
[user_one]
[user_two]
[user_three]
Im tried hhvm on my vServer and have problems with the memory used. The performance is great, but the used memory consumption is horrible. I have a vServer with min 4GB and max 8GB memory and hhvm uses after 1 day about 2.4GB of the available memory - but still rising.
Is there a option in server.ini to set the max memory which should be used for the hhvm process?
I'm currently running Typo3 and Prestashop inside hhvm
location ~ \.php$ {
try_files $uri =404;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
fastcgi_pass unix:/var/run/hhvm/hhvm.sock;
}
and server.ini
; php options
pid = /var/run/hhvm/pid
; hhvm specific
;hhvm.server.port = 9000
hhvm.server.file_socket = /var/run/hhvm/hhvm.sock
hhvm.server.type = fastcgi
hhvm.server.default_document = index.php
hhvm.log.use_log_file = true
hhvm.log.file = /var/log/hhvm/error.log
hhvm.repo.central.path = /var/run/hhvm/hhvm.hhbc
The HHVM wiki has a fairly complete list of options. I'm not aware of any one that controls maximum memory usage.
But what is the runtime supposed to do when it hits that maximum, anyways? I'm not sure it would be a useful option.
If you're seeing monotonically increasing memory usage over time, you should file a new issue on GitHub so we can help you get a heap profile and figure out what is causing the memory increase. That shouldn't be happening. There are a few known bugs that we might be able to help you work around -- any usage of create_function is known to leak right now, for example -- or maybe you've found some new leak that we can fix.
I've just installed a nginx+php-fpm server. Everything seems fine except that PHP-FPM never writes error to its log.
fpm.conf
[default]
listen = /var/run/php-fpm/default.sock
listen.allowed_clients = 127.0.0.1
listen.owner = webusr
listen.group = webusr
listen.mode = 0666
user = webusr
group = webusr
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
pm.status_path = /php/fpm/status
ping.path = /php/fpm/ping
request_terminate_timeout = 30s
request_slowlog_timeout = 10s
slowlog = /var/log/php-fpm/default/slow.log
chroot = /var/www/sites/webusr
catch_workers_output = yes
env[HOSTNAME] = mapsvr.mapking.com
php_flag[display_errors] = on
php_admin_value[error_log] = /var/log/php-fpm/default/error.log
php_admin_flag[log_errors] = on
nginx.conf
server
{
listen 80 default_server;
server_name _;
charset utf-8;
access_log /var/log/nginx/access.log rest;
include conf.d/drops.conf.inc;
location /
{
root /var/www/sites/webusr/htdocs;
index index.html index.htm index.php;
}
# pass the PHP scripts to FastCGI server listening on socket
#
location ~ \.php$
{
root /var/www/sites/webusr/htdocs;
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /htdocs/$fastcgi_script_name;
if (-f $request_filename)
{
fastcgi_pass unix:/var/run/php-fpm/default.sock;
}
}
location = /php/fpm/status
{
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/var/run/php-fpm/default.sock;
}
location = /php/fpm/ping
{
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/var/run/php-fpm/default.sock;
}
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html
{
root /usr/share/nginx/html;
}
}
I've made an erroneous php script and run, and see error output on the web browser. Also nginx error log states stderr output from fpm with the same message. I've check that the user have write (I've even tried 777) permission to the appointed log folder. Even the appointed error.log file has be created successfully by php-fpm. However, the log file is always empty, no matter what outrageous error has been made from php script.
What's going on?
[Found the reason quite a while later]
It was permission. Changed the owner to the sites's users solved the problem.
This worked for me:
; Redirect worker stdout and stderr into main error log. If not set, stdout and
; stderr will be redirected to /dev/null according to FastCGI specs.
; Default Value: no
catch_workers_output = yes
Edit:
The file to edit is the file that configure your desired pool.
By default its: /etc/php-fpm.d/www.conf
I struggled with this for a long time before finding my php-fpm logs were being written to /var/log/upstart/php5-fpm.log. It appears to be a bug between how upstart and php-fpm interact. See more here: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1319595
I had a similar issue and had to do the following to the pool.d/www.conf file
php_admin_value[error_log] = /var/log/fpm-php.www.log
php_admin_flag[log_errors] = on
It still wasn't writing the log file so I actually had to create it by touch /var/log/fpm-php.www.log then setting the correct owner sudo chown www-data:www-data /var/log/fpm-php.www.log.
Once this was done, and php5-fpm restarted, logging was resumed.
There are multiple php config files, but THIS is the one you need to edit:
/etc/php(version)?/fpm/pool.d/www.conf
uncomment the line that says:
catch_workers_output
That will allow PHPs stderr to go to php-fpm's error log instead of /dev/null.
I gathered insights from a bunch of answers here and I present a comprehensive solution:
So, if you setup nginx with php5-fpm and log a message using error_log() you can see it in /var/log/nginx/error.log by default.
A problem can arise if you want to log a lot of data (say an array) using error_log(print_r($myArr, true));. If an array is large enough, it seems that nginx will truncate your log entry.
To get around this you can configure fpm (php.net fpm config) to manage logs. Here are the steps to do so.
Open /etc/php5/fpm/pool.d/www.conf:
$ sudo nano /etc/php5/fpm/pool.d/www.conf
Uncomment the following two lines by removing ; at the beginning of the line: (error_log is defined here: php.net)
;php_admin_value[error_log] = /var/log/fpm-php.www.log
;php_admin_flag[log_errors] = on
Create /var/log/fpm-php.www.log:
$ sudo touch /var/log/fpm-php.www.log;
Change ownership of /var/log/fpm-php.www.log so that php5-fpm can edit it:
$ sudo chown vagrant /var/log/fpm-php.www.log
Note: vagrant is the user that I need to give ownership to. You can see what user this should be for you by running $ ps aux | grep php.*www and looking at first column.
Restart php5-fpm:
$ sudo service php5-fpm restart
Now your logs will be in /var/log/fpm-php.www.log.
There is a bug https://bugs.php.net/bug.php?id=61045 in php-fpm from v5.3.9 and till now (5.3.14 and 5.4.4). Developer promised fix will go live in next release. If you don't want to wait - use patch on that page and re-build or rollback to 5.3.8.
In your fpm.conf file you haven't set 2 variable which are only for error logging.
The variables are error_log (file path of your error log file) and log_level (error logging level).
; Error log file
; Note: the default prefix is /usr/local/php/var
; Default Value: log/php-fpm.log
error_log = log/php-fpm.log
; Log level
; Possible Values: alert, error, warning, notice, debug
; Default Value: notice
log_level = notice
I'd like to add another tip to the existing answers because they did not solve my problem.
Watch out for the following nginx directive in your php location block:
fastcgi_intercept_errors on;
Removing this line has brought an end to many hours of struggling and pulling hair.
It could be hidden in some included conf directory like /etc/nginx/default.d/php.conf in my fedora.
in my case I show that the error log was going to /var/log/php-fpm/www-error.log . so I commented this line in /etc/php-fpm.d/www.conf
php_flag[display_errors] is commented
php_flag[display_errors] = on log will be at /var/log/php-fpm/www-error.log
and as said above I also uncommented this line
catch_workers_output = yes
Now I can see logs in the file specified by nginx.
In my case php-fpm outputs 500 error without any logging because of missing php-mysql module. I moved joomla installation to another server and forgot about it. So apt-get install php-mysql and service restart solved it.
I started with trying to fix broken logging without success. Finally with strace i found fail message after db-related system calls. Though my case is not directly related to op's question, I hope it could be useful.
On alpine 3.15 with php8 i found on /var/log/php8/error.log
/var/log/php8 # cat error.log
16:10:52] NOTICE: fpm is running, pid 14
16:10:52] NOTICE: ready to handle connections
i also have this :
catch_workers_output = yes
Check the Owner directory of "PHP-FPM"
You can do:
ls -lah /var/log/php-fpm/
chown -R webusr:webusr /var/log/php-fpm/
chmod -R 777 /var/log/php-fpm/