Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

After upgrading nginx on my server, all PHP sites stopped working. Before, I had just this in the file "fastcgi_params":

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;

And then the PHP site config files had a block like this inside:

    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        include        fastcgi_params;
    }

However, this no longer works. It only works if I have this in the per-site config files:

    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }

I have to have the SCRIPT_FILENAME being set here, and not in "fastcgi_params". It also has to have $document_root in front of it now. Neither "$document_root$fastcgi_script_name" nor "$fastcgi_script_name" work if set in the included fastcgi_params file.

I'm not that concerned that I now have to prepend it with $document_root (but I am curious, if anyone knows why that broke or why it was working before), but I'd prefer to keep common functionality in the fastcgi_params file for simplicity so I'd like to know why that isn't working.

share|improve this question
    
I assumed this was an nginx issue (it might still be), but I also upgraded from PHP 5.2 to 5.3.3, which is the first build with FPM built-in. A friend has a config almost identical to my previous one, which is working with PHP 5.3.0 and the FPM patch. –  ZoFreX Nov 3 '10 at 21:28
add comment

2 Answers

up vote 1 down vote accepted

I'm going to guess that your config is probably a "series" of bad practices so I recommend you read this: http://blog.martinfjordvald.com/2010/07/nginx-primer/

In short, you can (and should) put fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; into your fastcgi_params (or just include the fastcgi.conf file instead) but due to how nginx inherits configuration values between levels you need to make sure that your root directive is defined in the server block and not in location /.

This is in general very good advice, put as much as possible in the upper most level and you'll avoid a ton of duplication.

share|improve this answer
    
What makes you think my config is so terrible? Is there something bad in the snippets I posted? I tried moving the "include fastcgi_params" outside the location block but that didn't work (bad gateway). The blog you linked is down, I'll try again to reach it later. –  ZoFreX Nov 4 '10 at 9:35
    
No. There's nothing wrong in the 3 lines you've pasted. I'd like to see more before I make an actual statement, so far I'm just guessing based on what you've said. A bad gateway actually means it's working, it's passing properly to the backend but there's nothing there listening. That said, I did not say move the include fastcgi_params, I said you should move the fastcgi_param into the fastcgi_params file and move the root directive to server level. –  Martin Fjordvald Nov 4 '10 at 17:06
    
I've accepted this answer as @vimalg2 had the exact same issue as me, and this advice fixed it for them –  ZoFreX Oct 16 '13 at 13:54
add comment

Something broke 'passing the execution to php-fpm' functionality after the latest upgrade to 0.8.53-0ppa5~lucid version for my launchpad.net/~nginx/+archive/stable ppa version of nginx. I'm running 10.04 LTS x64. The problem surfaced on all my Ubuntu 10.04 LTS Servers and VPSs when I auto-upgraded the nginx from the above ppa repo. https://launchpad.net/~nginx/+archive/stable

I fixed it for the time being by downgrading to the Ubuntu 10.04 LTS Canonical packaged repo version of 7.65. http://packages.ubuntu.com/lucid/nginx

I've tried many permutations of the affected parameter -> $script_filename , with no Luck.

Oddly, I thought this had something to the fact that they have added a line for defining $SCRIPT_FILENAME inside fastcgi_params .

  • Bugfix: Added SCRIPT_FILENAME to fastcgi_params

(from https://launchpad.net/~nginx/+archive/stable/+packages , click on the lucid package to see the Changelog with above line) It seems to have no effect whatsoever; I gave up and downgraded to save my production PHP sites.

I'd like to know if anyone can get another POV on this issue.

Please upvote if you are affected by this too.

I'm not sure what sort of QA is in place for the ppa repos marked as stable in launchpad. (I'm a relative newbie to the Launchpad world.)

share|improve this answer
    
Have you tried "fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;"? –  ZoFreX Nov 7 '10 at 16:15
    
I haven't tried that in the indiviudal vhost config; But, like i said, the nginx team have added that line by default to the fastcgi_params config file in the app_root for the LATEST release. Since i'm including that in each 'vhost' config file, it should have the same effect right? –  vimalg2 Nov 8 '10 at 5:23
    
I thought it SHOULD, but that's exactly the problem I have - it isn't. I have to put that param (and only that one) in the location block. –  ZoFreX Nov 8 '10 at 11:57
1  
Hey, ZoFreX, It turns out that Martin F's advice regarding putting the 'root <www path arg>' directive under/inside the 'server { ' Block works. I moved that fastcgi_param back to the master fastcgi_params file that all configs inherit from; Everything is resolved on my Nginx 8.53 + PHP5.30 +FPM configuration. –  vimalg2 Nov 9 '10 at 5:02
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.