Re: PHP-FPM fails to start scripts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24/05/17 02:05, John Iliffe wrote:
> On Tuesday 23 May 2017 02:40:03 Lester Caine wrote:
>> On 23/05/17 02:41, John Iliffe wrote:
>>> The Apache directive invoking this script is:
>>> 	ProxyPassMatch "^/.*\.php(/.*)?$" fcgi://127.0.0.1:9015/httpd/iliffe/
>>
>> ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9015/httpd/iliffe/$1
>> was your original line, and this should have resulted in the right
>> trimming of slashes while I think you are currently getting the double
>> slash because of the trailing one in your current string.
>>
> Please ignore this following paragraph.  It was an attempt at a minimalist 
> ProxyPassMatch that would bypass any regex errors.  It isn't useful in the 
> real world so I dropped trying it.  I think you got that info from the 
> Apache mailing list.

I suggested it simply because it would bypass some errors ;)

>> ProxyPassMatch ^/info$ fcgi://127.0.0.1:9015/httpd/iliffe/i_phpinfo.php
>> and http://localhost/info should work ... but is /httpd REALLY a root
>> folder? I'm getting /srv/www/htdocs as the default root, and I switch to
>> /srv/website/test.com for each website ...
>>
> Some further info: 
> 
> Yes, /httpd is the root directory for the web pages.  The production server 
> has a lot of named virtual hosts on it and each one has a document root of 
> /httpd/<server name>/  and the test server is set up the same way.  The 
> test server is www.iliffe.ca and its document root thus becomes /httpd/iliffe 
> plus a few subs below that where needed.  In this case, there are no 
> additional subs.

One of the major problems with Linux is the way each distribution
modifies just where it installs key applications and how it manages
them. I'm on SUSE myself and apart from a couple of attempts at other
distros when the SUSE guys just totally lost the plot, I've been with
that since version 6. My problem is installing later APACHE/PHP builds
while maintaining the stable SUSE installs ... and getting paths right
teds to be the problem.

> When I tried the $1 extension as you suggested it didn't work, see previous 
> memo; so I removed the $1 and also the last '/' in the ProxyPassMatch 
> directive and now php-fpm has the correct path and file but without the 
> double '//'.  So, this is one case where a trailing / on a directory does 
> not work/isn't required.  Here is the strace record:
> 
> -------------------------------
> 5254  20:14:55 lstat("/httpd/iliffe/i_phpinfo.php", {st_mode=S_IFREG|0644, 
> st_size=213, ...}) = 0
> --------------------------------
> 
> php-fpm received a 0 from lstat (file exists), is a regular file (S_IFREG) 
> and is readable (0644).  So that makes no difference to the result.  php-fpm 
> still backs down the directory tree and then tries to stat the wrong file 
> name.  Just for completeness, here is the php-fpm log entry:
> 
> ----------------------------------
> [23-May-2017 20:14:55] WARNING: [pool www] child 5254 said into stderr: 
> "ERROR: Unable to open primary script: /httpd/iliffe/i_phpinfo.php (No such 
> file or directory)"
> ---------------------------------

THAT is telling me that /httpd/iliffe/i_phpinfo.php is not the path to
the file. Bit like one gets with windows where it hides the real
physical location and only gives you a 'user' view of the path. My copy
of Apache is using wwwrun:www user when it is running, so all of the
/<server name> folders and files have that user name and group, but even
with that php should be able still to read the file so I'm still
thinking the path is wrong in some way. A quick search on Fedora give
/var/www/html/ as the default where SUSE gives me /srv/www/htdocs ...

> I haven't been able to find out yet if the parameter data is picked up when 
> the Apache directive is coded this way.   (eg:   i_phpinfo.php?a=b&c=d)  
> 
> I seem to be getting a good argument here for backing off to PHP5!

If there was a good security reason for changing the PHP5.4 machines I'm
still running then I'd move, and eaccelerator still provides all the
speed improvement I need, so I'm not surprised three quarters the world
has yet to even move to a higher version of PHP5 ... and less that 5%
are using PHP7 front facing.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux