Tag Info

New answers tagged

0

try this: Note: Used only when pm is set to 'dynamic' pm.start_servers = min_spare_servers + (max_spare_servers - min_spare_servers) / 2 pm = dynamic pm.max_children = 500 pm.start_servers = 60 pm.min_spare_servers = 20 pm.max_spare_servers = 100 pm.max_requests = 10000; or like this: pm = ondemand pm.max_children = 500 pm.max_requests = 10000 ...


0

Based on the output: Unable to open primary script: /usr/share/nginx/C:/xampp/htdocs/lara/public/index.php (No such file or directory) It appears you're referencing Windows-style paths (C:/), but running nginx on a Linux virtual machine (/usr/share/nginx). By default, Vagrant shares only one folder, which is the project folder on your host machine ...


0

WordPress hard-codes the site URL within its code, so you will need to change it there. From this link, you can add these lines in your site's wp-config.php file: define('WP_HOME','http://mycomputer.my.domain'); define('WP_SITEURL','http://mycomputer.my.domain');


0

In case it helps... I had systematic 500 Internal Errors and had to struggle a lot to make php-fpm work with Apache and IPSCONFIG on a Ubuntu 14.04 LTS Trusty, build with Falko tutorial This is my working PHP-FPM configuration: /etc/php5/fpm/pool.d/www.conf user = www-data group = www-data listen.owner = www-data listen.group = www-data listen.mode = ...


2

This note helped me: https://bugs.launchpad.net/nginx/+bug/1366651 In my case, updating to nginx > 1.6.1 the parameters that are passed to php5-fpm are located in fastcgi.conf instead of in fastcgi_params, resulting in a PHP that always returns 200 (ok), but never any content, because the SCRIPT_FILENAME was no longer set. I hope it also helps someone ...


0

You could also try defining a location block by @name and referencing it. From nginx Pitfalls page server { location ~ \.php$ { try_files @fascgi; } location ^~ /folder { deny all; allow 127.0.0.1; location ~ \.php$ { try_files @fascgi; ...


4

You should also update the wordpress configuration. Without that, wordpress still links the static content to subdirectory. Step taken from Moving your Wordpress from a subfolder to the root directory From the main dashboard, go to Administration -> Settings -> General. Next, look for the WordPress address (URI): and change it from (example.com/wordpress ...


0

This is bug 56858 to be fixed in in the next release of 2.4.x (2.4.11?) Here's the patch: http://svn.apache.org/viewvc?view=revision&revision=1621602


1

You can create different fpm pools listening on different ports (or unix sockets) and assing different sites or even different locations or applications to use these pools. This way whan one pool is saturated with some laggy script, others won't be affected.


0

Try with FilesMatch \.php$ instead of ProxyPassMatch. Eg. <FilesMatch \.php$> SetHandler "proxy:unix:/var/run/php5-fpm.sock|fcgi://localhost" </FilesMatch> See a full example: Dynamic development area with Apache 2.4 and PHP-FPM I hope this help.


1

Just check nginx & php-fpm running user. ps aux | grep nginx ps aux | grep php-fpm they should work with the same user (probably nginx as i see in your config) then check that user if it can read the file. su - nginx -c "cat /usr/share/nginx/html/phpinfo.php"


2

The first things I would try in this case is to double-check the permissions on the files you are trying to read, just in case a startup script caused them to be changed. "ls -l /var/www/" would let you see this, where /var/www/ is your web root. Then, try turning on error reporting in the php configuration to see if PHP reports any additional errors when ...


3

OP stated that his working solution is sudo chmod -R 0777 app/storage. While it solved the problem, it is never the solution. The proper way is set the group as www-data and give it write permission. chown -R www-data app/storage chmod -R 0770 app/storage For details explanation about chmod 777 and permissions on a Linux webserver, see this answer: What ...


0

Ok, I was able to solve it myself. There were a number of problems. "php5" needed to replace almost every instance of "php". The bad connection I was receiving was referring to the unixsocket so I had to update that as well. Also the new PID location changed it looks like with PHP5-FPM. Here is the final configuration. ## Check PHP-FPM check process ...


-1

change www.conf user = nginx group = nginx change fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; into fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; and also check, do you have httacess file in /var/www/html. usually this cause that problem


1

mod_proxy_fcgi adds response headers to r->err_headers_out which means you should use at least: Header unset X-Userid always But there is no reason to not use both: Header always unset X-Userid Header unset X-Userid This is an unfortunate part of the Apache API that bleeds into mod_headers -- headers can live in two places depending if they're meant to ...


0

I've solved the problem. I didn't make any changes to my configs. I've just done "aptitute update && aptitude upgrade" and voila - now it works with my configs listed above. So I think that was a bug.


0

So you run a pool in chroot, but your paths are pointing to the directory tree without chroot. You should change the paths in the fastcgi_param options to reflect the actual path inside the chroot, so the chrooted php-fpm gets a proper understanding where to look for the php scripts.


0

Switch PHP-FPM to ondemand and set the timeout values lower than they currently are.


1

Look like an old bug not resolved yet: https://bugs.php.net/bug.php?id=62382



Top 50 recent answers are included