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
Related
I cannot launch php-fpm on OpenSUSE.
When I run systemctl restart php-fpm.service
I receive the following error, after copying etc/php8/fpm/php-fpm.conf.default to etc/php8/fpm/php-fpm.conf
[25-Apr-2021 12:52:18] ERROR: failed to open configuration file '/etc/php8/fpm/php-fpm.conf': Permission denied (13)
[25-Apr-2021 12:52:18] ERROR: failed to load configuration file '/etc/php8/fpm/php-fpm.conf'
[25-Apr-2021 12:52:18] ERROR: FPM initialization failed
I had to switch to php7-fpm to make it works.
It seems that php-fpm does not work properly on OpenSUSE Tumbleweed.
No problem with apache mod php.
I had some of the issues as can be found in your post.
My setup:
php8 with nginx (fast-cgi NOT USING SOCK) works fine on my laptop
hardware: HP mobile workstation Compaq 8510w
Yes, I know, that is not the latest gear, but its very solid and stable.
It looks like it has been made for Linux!
Micros....urged me to upgrade it from W7 to W10
but left me alone with unsolvable issues. Their Troubleshooter told me
"Ask a friend" and that is what I did.
The friend said, try linux and that is why I am here now.
I never regretted and this is the only reason to say "Thank you Micros..."
Operating System: openSUSE Tumbleweed 20210
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.85.0
Qt Version: 5.15.2
Kernel Version: 5.13.8-1-default (64-bit)
Graphics Platform: X11
Processors: 2 × Intel® Core™2 Duo CPU T9300 # 2.50GHz
Memory: 3.8 GiB of RA
Graphics Processor: AMD RV630
for peace of mind:
nginx and php have numerous safety-features.
Safety is very important, so keep an eye on the common IT-safety rules,
but be aware, that safety-rules can lock you out, if not implemented correctly.
Before doing any editing make backups of all original configuration files
for convenience:
I installed mc (Midnight Commander) and use nano as editor.
I added myself to the group wheel, so that I can use sudo without having to enter my password.
mc is very convenient for changing directories, jumping from file to file and editing configuration files, because you can use mc as root. Besides that you can easily change to the shell and back i.E to modify permissions or to use other shell-commands.
Further:
I created aliases in .bashrc enabling starting, stopping and checking
services with shortcuts.
alias sto='sudo systemctl stop $2'
alias str='sudo systemctl start $2'
alias rst='sudo systemctl restart $2'
alias sta='sudo systemctl status $2'
alias sn='sudo nano $2'
How to use them?
After editing your .bashrc do a
source .bashrc
To use these aliases you type the aliasname, a blank and the path to the file like for example for editing a file als sudo with nano try:
sn /etc/rc.local
or, to retrieve the status of php-fpm with just a few keystrokes:
sta php-fpm
I copied /etc/php8/php.ini to "php.ini.commented" and deleted all comments and non required options in the original
I also copied /etc/php8/cli/php.ini to php.ini.commented and deleted all
comments and non required options in the original
I did the same with /etc/php8/fpm/php-fpm.d/www.conf
for avoiding conflicts:
Before any other software operation, make sure that your system is running without errors.
Use
dmesg -l err
or
journalctl -b |grep error
Solve found errors first!
After verification you should execute a
sudo zypper dup
do not change more than 1 parameter per trial, when testing/modifying your configuration.
Check for result of modifications in logfiles after each step.
write comments in the modified config and -if using an advice from a website- paste the web-address as a comment since in a few days you might not remember why you configured as you did.
avoid multiple blanks in comments in configuration files, this can lead to a "parse error".
I use the pathnames as they are being configured by setup.
Do it like this, it will prevent problems after software-updates.
I did not use the original Tumbleweed user/group "wwwrun" and "www", instead I created a user "www-data" in group "www-data" exactly as in Raspberry debian 10.
with following commands
sudo chown -R www-data:www-data /srv
sudo chmod -R 755 /srv
I have changed ownership and permissions of all contents, that will be accessed by php-fpm.
In case you place symlinks in /srv/www/public to files elsewhere, you need to change the permissions in the files, the link is pointing to. For example if you create a symlink in /srv/www/public to your phpmyadmin data, you need to change the permissions for all files in /usr/share/mysql/phpmyadmin.
The user of the data in your pool /srv/www/public must be the same as the user, defined in /etc/nginx/nginx.conf, and
when using a pool named "public", user and group in the section [public] in /etc/php8/fpm/php-fpm.d/www.conf must also be the same .
This is crucial, most problems at startup of nginx are caused by wrong permissions.
STEP BY STEP
Begin with a basic setup, without any special features.
On request of friends I added my functional configuration files below
Do not copy configurations from it-specialists in the web, who might do complicated or exotic things, proxies, remote servers etc.
Especially if in those configurations there are expressions you don't understand , better don't use them.
Just get started, undo temporary solutions as soon as nginx is operational and make a backup of the first working basic configuration.
After that -but not earlier- you can start experimenting
Never use chmod 777 in any of the above directories, because that's is an invitation to get your system hacked.
Never change the mod 644, owner root:root in /var/log
The logfiles of php-fpm are being created and modified by root. Logfiles contain sensitive info.
Verify correct setup with:
ps -aux |grep php
The result should be similar to following lines. This means that php-fpm is being run by root:
root 1262 0.0 0.3 54024 13260 ? Ss 06:12 0:01 php-fpm: master process (/etc/php8/fpm/php-fpm.conf)
www-data 1335 0.0 0.2 54172 9576 ? S 06:12 0:00 php-fpm: pool public
Allowing access to anybody else is opening the doors for hackers. Keep in mind that you are using a browser to see your data, but other people may be able to browse them as well.
After having a running system it is easy to add further steps.
To start up there is no need for using sites-enabled in nginx
and you need to create just one pool in /etc/php8/fpm/php-fpm.d/www.conf
TROUBLESHOOTING FREQUENT ERRORS:
MySql-errors:
I presume here, that your mariadb/mysql has been setup correctly.
Missing or wrong permissions will cause "not found" errors.
Troubleshooting in mysql is documented very well and mysql has an interactive help function. Read the documentation and test access following steps of the mysql manuals. It would lead too far, to add a guide for that to this document.
php-fpm not starting:
failed to open configuration file '/etc/php8/fpm/php-fpm.conf': Permission denied (13)
With
sudo systemctl status php-fpm
you will find more details about what and how.
Possibly there is an access-issue when php-fpm tries creating a logfile "access.public.log" in /var/log by following the line access.log = "access.$pool.log" (look in file www.conf).
This error can be caused/suppressed by settings in apparmor.
Options are:
temporary disable apparmor
sudo systemctl stop apparmor
sudo systemctl disable apparmor
In openSUSE You can use Yast to configure apparmor
In case you made modifications the result can be found as below in:
/etc/apparmor.d/php-pfm
vim: ft=apparmor
profile php-fpm /usr/sbin/php-fpm* flags=(attach_disconnected, complain) {
include <abstractions/base>
include <abstractions/nameservice>
include <abstractions/openssl>
include <abstractions/php>
include <abstractions/ssl_certs>
include if exists <local/php-fpm>
include if exists <php-fpm.d>
capability chown,
capability dac_override,
capability kill,
capability net_admin,
capability setgid,
capability setuid,
signal send peer=php-fpm//*,
deny / rw,
/etc/php8/fpm/php-fpm.conf r,
/etc/php{,5,7}/* r,
/usr/sbin/php-fpm* rix,
owner /var/log/php*-fpm.log rw,
owner /var/log/public.acess.log rw,
#{PROC}/#{pid}/attr/{apparmor/,}current rw,
#{run}/php{,-fpm}/php*-fpm.pid rw,
#{run}/php{,-fpm}/php*-fpm.sock rwlk,
owner /etc/php8/fpm/php-fpm.d/www.conf r,
change_profile -> php-fpm//*,
}
or temporary comment the line
access.log = /var/log/$pool.access.log in your www.conf
To get started this file is not absolutely required
and commenting it helped me to suppress the "php-fpm could not be started" error.
The most important and detailed logfile is
/var/log/nginx/error.log
To debug, after every modification You should use
sudo tail -1 /var/log/nginx/error.log
You will see that most errors are permission errors either because mysql can't access your database or php-fpm can't use your php/html-files!
here my /etc/nginx/nginx.conf:
user www-data;
worker_processes auto;
#pid /run/nginx.pid; not required when using tcp
events {
worker_connections 1024;
use epoll;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
include /etch/nginx/conf.d/*.conf;
server {
listen 80;
server_name 127.0.0.1;
root /srv/www/public; # without this root instruction nqinx will use /usr/ as prefix and you will get a not found error!
error_page 500 502 503 504 /50x.html; # redirect server error pages to the static page /50x.html
location = /50x.html {
root /srv/www/htdocs/;
}
location ~ \.php$ { # 404
try_files $fastcgi_script_name =404;
include /etc/nginx/fastcgi_params;
# default fastcgi_params
# fastcgi settings
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
# fastcgi params
fastcgi_param DOCUMENT_ROOT /srv/www/public;
fastcgi_param SCRIPT_FILENAME $request_filename;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
location / {
root /srv/www/public;
try_files $uri $uri/ =404;
index index.nginx-debian.html index.php index.html index.htm;
}
location ~ /\.ht {
# deny access to .htaccess files, if Apache's document root concurs with nginx's one
deny all;
}
include vhosts.d/*.conf;
}
}
filecontents of /etc/php8/fpm/php-fpm.d/www.conf
[public]
prefix = /srv/www/$pool
user = www-data
group = www-data
listen = 127.0.0.1:9000
;use these settings only if a socket is used
;listen.owner = www-data
;listen.group = www_data
;listen.mode = 0660
pm = static
pm.max_children = 1
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 500
; this optional feature is well documented in the file and further instructions for how to set it up can be found on the web
pm.status_path = /status
; if fpm-phm cannot start, temporary comment the two lines access.log, but reactivate the instructions as soon as php-fpm is operational
; if there are wrong permission-settings, php-fpm will not start
access.log = /var/log/$pool.access.log
access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{mili}d %{kilo}M %C%%"
catch_workers_output = yes
security.limit_extensions = .php .html
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
php_admin_value[error_log] = /var/log/fpm-php.www.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 32M
file /etc/php8/fpm/php-fpm.conf
; FPM Configuration ;
[global]
process_control_timeout = 10
process.max = 128
daemonize = no
rlimit_core = 0
rlimit_files = 1024
events.mechanism = epoll
systemd_interval = 10
include=/etc/php8/fpm/php-fpm.d/*.conf
With this configuration I run several mysql-databases and content management as well as phpmyadmin.
The picture below is a screenshot of my Content Management System using a mysql database and self-designed forms in php-format.
In the location definitions there are no further instructions required, neither for loading stylesheets nor for pictures/movies.
A check with Google's developer tools in Chrome proofs, that all references and links to stylesheets, json-files and further directories have been found and that there are no errors.
Of course it took me some time to get all this running.
This answer may help everybody who wants to set up nginx and save time.
The documentation of nginx and php is complete and excellent. For most commands there is a --help option, man pages and a webpage.....
Yes, I know!
Help and man-pages are written by excellent IT-engineers,
some of these hexadecimal-thinking people might have difficultes
to translate their digital slang to human-understandable language.
That's why some pages are more confusing than helping.
Anyway, press the F1-key, try the help and forgive them.
Where would we be without them?
In my little network here, I am using a 24/7 running Raspberry Pi 3 B+ with 64 bit OS as server, that stores data on two USB drives.
The configuration for accessing local files on this server is nearly the same as the configuration on my laptop.
There are just two little differences:
On "debian buster" the application php8 is named php8.0 and a few directories have different names, so you can use above configuration files for Raspberry debian buster with the following restriction: the pertinent 'include' lines are different and need to be altered according to the location-names of the config-files .
My nginx.conf on the Raspberry-server has a few lines of extra code, in order to enable access to contents via DDNS, but that is a different chapter.
I would like to emphasize that I am not an IT-specialist. I have collected some experience in computing during my professional activities as mechanical engineer, all further know-how came from pressing the F1-key, reading forum-contributions, manuals, helpfiles, webpages and -not to forget- from made mistakes.
I hope that this may encourage others, to keep trying. Linux is structured very clearly and can be understood easily. Google errors, watch your logfiles attentively and enjoy the fun of finally running a fully operational php-fpm/nginx.
I need to remind you once more:
Don't forget to reset all temporary solutions.
Cheers
This is related to apparmor settings. Please edit /etc/apparmor.d/php-fpm:
19 /etc/php{,5,7,8}/** r,
to allow access to directory /etc/php8/ by php-fpm process.
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.
UPDATE
Still in pain ... nothing found :(
I'm honestly willing to donate to anyone who could jelp me solve this, it's getting obsessional lol.
On a Proxmox distrib, I have a VM with a Debian installed.
ON this Debian : Nginx / PHP5-FPM / APC / Memcached and MySQL are running with a big MAGENTO multi-website setup.
Sometimes, (randomly or around 9am depends) The server load is increasing.
What I can see during this peek is :
High number of PHP-FPM instances in HTOP
Higyh number of MySQL connexions with most of them in sleeping state with a big "moment" value like 180 or sometimes more.
Server's memory is not full, free -h tells me memory is not the issue here.
TCP connexions from visitors is not high so, I don't think trafic is the issue neither
Looks like there is something (a php script I would say), that is triggered either by the cron or by a visitor (like a research or something else), and it's taking a lot of time to process, probably locking some MySQL tables and preventing other processes to run, leading to a massive freeze.
I'm trying hard to figure out what is causing this problem, or just find "ways" to debug it eficiently.
What I tried already :
Tracing some of the php processes with HTOP to find
some informations. That's how I found out that mysql's process had some message idnicating it cannot connect to a ressource because it was busy.
Searched in /var/log/messages and /var/log/syslog for information but got nothing relevant.
Searched in /var/log/mysql for some error logs but got nothing at all.
Searched in /var/log/php5-fpm.log and got many messages indicating that processes are exiting with code 3 after a "LONG" period of time (probably the process trying to get mysql ressource and never getting it ?) like :
WARNING: [pool www] child 23839 exited with code 3 after 1123.453563 seconds from start
or even :
WARNING: [pool www] child 29452 exited on signal 15 (SIGTERM) after 2471.593537 seconds from start
Searched in Nginx website's error file and found multiple messages indicating that visitors connexions timed out due to the 60 seconds timeout I set in Nginx config file.
Here are my settings :
Nginx website's config file :
location ~ \.php$ {
if (!-e $request_filename) {
rewrite / /index.php last;
}
try_files $uri =404;
expires off;
fastcgi_read_timeout 60s;
fastcgi_index index.php;
fastcgi_split_path_info ^(.*\.php)(/.*)?$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
Nginx main config file :
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
fastcgi_read_timeout 60;
client_max_body_size 30M;
PHP-FPM is in onDemand mode
default_socket_timeout = 60
mysql.connect_timeout = 60
PHP-FPM pool's config file
pm=ondemand
pm.max_children = 500
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.process_idle_timeout = 10s;
pm.process_idle_timeout = 10s;
pm.max_requests = 5000 (was thinking about reducing this value to force processes to respawn, if someone has experience with it, I'm interested in hearing it)
Thank you for your time reading this, I will update the content here if needed.
Regards
Sorcy
Did you check the cronjobs in crontab and Magento to make sure this is not any job?
Does this weird server behaviour slowdown your site? Im not sure, but this can also be an Slowloris DDos attack, where a lot HTTP connections open and because of a bug doesnt get closed. Maybe I gave you a hint with that.
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/