Thomas wrote:
Hi,
In my PHP+nginx combo, I have a little problem.
Let’s say I have phpmyadmin installed in /var/www/phpmyadmin,
in nginx.conf I must specify fastcgi_param SCRIPT_FILENAME
/var/www/phpmyadmin$fastcgi_script_name;
I tried using fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
but it doesn’t work. In the browser I get a “no input file specified”.
How to solve this issue. I know it’s meaningless, but it’s annoying to
have to remember to change the SCRIPT_FILENAME each time I move or
rename my php apps directory.
change location to /
location / {
fastcgi_pass localhost:8000;
fastcgi_index get;
fastcgi_param SCRIPT_FILENAME
/home/fs01/www$fastcgi_script_name;
fastcgi_param SCRIPT_NAME
$fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
this makes all php requests to go to the fastcgi daemon.
That’s what I alreay have, but based on this documentation:
http://wiki.codemongers.com/NginxFcgiExample, “To use Nginx + Virtual
Host + PHP you should ommit the SCRIPT_NAME variable in order for PHP
to choose the correct DOCUMENT_ROOT.”
it seems that you can replace /home/fs01/www with $document_root, that
would save me some time and headaches when renaming a folder.
But probably I am wasting time on an insignificant improvement.
On Jan 25, 2008 5:44 PM, Stefanita rares Dumitrescu
By the way, why not launching and monitoring nginx using daemontools
instead of init.d?
Who is doing this?
On Jan 26, 2008 12:07 PM, Stefanita rares Dumitrescu
Thomas wrote:
That’s what I alreay have, but based on this documentation:
http://wiki.codemongers.com/NginxFcgiExample, “To use Nginx + Virtual
Host + PHP you should ommit the SCRIPT_NAME variable in order for PHP
to choose the correct DOCUMENT_ROOT.”
it seems that you can replace /home/fs01/www with $document_root, that
would save me some time and headaches when renaming a folder.
But probably I am wasting time on an insignificant improvement.
On Jan 25, 2008 5:44 PM, Stefanita rares Dumitrescu
that’s worth trying 
but it has impact only when renaming document
root, which in this case is /home/fs01/www
On Sat, Jan 26, 2008 at 05:00:21PM +0100, Thomas wrote:
By the way, why not launching and monitoring nginx using daemontools
instead of init.d?
In this case you will be unable to do online upgrades.
Stefanita rares Dumitrescu wrote:
Igor S. wrote:
On Sat, Jan 26, 2008 at 05:00:21PM +0100, Thomas wrote:
By the way, why not launching and monitoring nginx using daemontools
instead of init.d?
In this case you will be unable to do online upgrades.
what do you mean?
Welcome back igor btw 
On Sat, Jan 26, 2008 at 08:30:03PM +0100, Stefanita rares Dumitrescu
wrote:
Igor S. wrote:
On Sat, Jan 26, 2008 at 05:00:21PM +0100, Thomas wrote:
By the way, why not launching and monitoring nginx using daemontools
instead of init.d?
In this case you will be unable to do online upgrades.
what do you mean?
After online upgrade daemontools can not monitor a new master process,
because daemontools is not its parent: its parent is the init, process
number 1.
Igor S. wrote:
On Sat, Jan 26, 2008 at 08:30:03PM +0100, Stefanita rares Dumitrescu
wrote:
Igor S. wrote:
On Sat, Jan 26, 2008 at 05:00:21PM +0100, Thomas wrote:
By the way, why not launching and monitoring nginx using daemontools
instead of init.d?
In this case you will be unable to do online upgrades.
what do you mean?
After online upgrade daemontools can not monitor a new master process,
because daemontools is not its parent: its parent is the init, process
number 1.
but that’s just gonna get solved by killall -9 process, and daemontools
will simply run it, and issue solved.
but that’s just gonna get solved by killall -9 process, and daemontools
will simply run it, and issue solved.
Yes, but this is not gracefull online upgrade without interruption
of the client processing. This is usual hard stop/start upgrade.
Actually, I never use daemontools/etc because nginx’s master process
has almost the same chances to fail as daemontools itself.
im just using daemontools for spawn-fcgi not nginx itself anyways.
On Sat, Jan 26, 2008 at 09:49:36PM +0100, Stefanita rares Dumitrescu
wrote:
In this case you will be unable to do online upgrades.
what do you mean?
After online upgrade daemontools can not monitor a new master process,
because daemontools is not its parent: its parent is the init, process
number 1.
but that’s just gonna get solved by killall -9 process, and daemontools
will simply run it, and issue solved.
Yes, but this is not gracefull online upgrade without interruption
of the client processing. This is usual hard stop/start upgrade.
Actually, I never use daemontools/etc because nginx’s master process
has almost the same chances to fail as daemontools itself.
Actually, I never use daemontools/etc because nginx’s master process
has almost the same chances to fail as daemontools itself.
Ok. I was just wondering if it made sense.