All of a sudden 500 server error

jackie46

BANNED
Jul 25, 2005
536
0
166
We have been running phpsuexec for awhile. All of a sudden today, every php site gets a 500 server error. Nothing was changed but after we determined php was down on every site we recompiled php. This did not fix the error. I think we have recomplied about 5 times now.

Whats up with this? Was working all of a sudden its stops working. This must be a Release issue. :confused: No sessions in /tmp owned by nobody. There are no .htaccess files accessing php functions either. :mad:
 

jackie46

BANNED
Jul 25, 2005
536
0
166
This is ridiculous!

Now im recompiling the entire RHEL 3 box with phpsuexec disabled because nothing works. It has been working for 2 days without issues and we have it running on all our other boxes without issues. Why all of a sudden did php take a big dump?

Also php -v shows

PHP 4.3.11 (cli) (built: Sep 22 2005 01:19:05)
Copyright (c) 1997-2004 The PHP Group


This is wrong! If you compile php and the entire box as phpsuexec it should be showing

PHP 4.3.11 (cgi) (built: Sep 22 2005 01:19:05)
Copyright (c) 1997-2004 The PHP Group

Why does php show CLI?
 
Last edited:

sparek-3

Well-Known Member
Aug 10, 2002
2,021
226
368
cPanel Access Level
Root Administrator
jackie46 said:
Not sure why you sent me to this link. Im saying, if you recompile Apache + phpsuexec when you type php -v it should be reporting that its running as a (CGI) module not a (CLI) module.
What php binary are you running, when you type:

Code:
which php
What does it show? If it does not show /usr/bin/php, then try running:

Code:
/usr/bin/php -v
that should show as CGI.

I suspect that which php will show /usr/local/bin/php and this is a CLI php.

PHP through phpsuexec should use the php binary in /usr/bin/php which should be a CGI binary.
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,453
31
473
Go on, have a guess
jackie46 said:
We have been running phpsuexec for awhile. All of a sudden today, every php site gets a 500 server error. Nothing was changed but after we determined php was down on every site we recompiled php. This did not fix the error. I think we have recomplied about 5 times now.

Whats up with this? Was working all of a sudden its stops working. This must be a Release issue. :confused: No sessions in /tmp owned by nobody. There are no .htaccess files accessing php functions either. :mad:
You haven't said what you've found in your apache error or suexec logs which is the first place that you should look.

If you have an urgent problem, then you shouldn't be relying on the forums but should hire a server admin to investigate for you if you don't know how.
 

jackie46

BANNED
Jul 25, 2005
536
0
166
sparek-3 said:
What php binary are you running, when you type:

Code:
which php
What does it show? If it does not show /usr/bin/php, then try running:

Code:
/usr/bin/php -v
that should show as CGI.

I suspect that which php will show /usr/local/bin/php and this is a CLI php.

PHP through phpsuexec should use the php binary in /usr/bin/php which should be a CGI binary.

YEP! Thats what i discovered before i answered. When i compile with phpsuexec it places the binary in /usr/bin but when you type which php it shows its in /usr/local/bin which is a (CGI) binary :confused:

If i type /usr/bin/php -v it shows the (CGI)

If i type /usr/local/bin/php -v its shows (CLI)

The question is, why is easyapache placing my compiled binary into /usr/local/bin and how do i get it to use the (CLI) in /usr/bin? I added the include_path to php.ini but that didnt fix it.
 

jackie46

BANNED
Jul 25, 2005
536
0
166
chirpy said:
You haven't said what you've found in your apache error or suexec logs which is the first place that you should look.

If you have an urgent problem, then you shouldn't be relying on the forums but should hire a server admin to investigate for you if you don't know how.

No thanks, im a pretty good admin. I cant help Cpanel screwups!
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,453
31
473
Go on, have a guess
The issue is nothing to do with cPanel and everything to do with apache and how you configure your server. From what you're saying you clearly don't understand it and so should either seek help from a proper server admin or hire one. These forums are not here to provide support to you, then for exchanging information, please don't abuse them.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,021
226
368
cPanel Access Level
Root Administrator
jackie46 said:
YEP! Thats what i discovered before i answered. When i compile with phpsuexec it places the binary in /usr/bin but when you type which php it shows its in /usr/local/bin which is a (CGI) binary :confused:

If i type /usr/bin/php -v it shows the (CGI)

If i type /usr/local/bin/php -v its shows (CLI)

The question is, why is easyapache placing my compiled binary into /usr/local/bin and how do i get it to use the (CLI) in /usr/bin? I added the include_path to php.ini but that didnt fix it.
If you run a phpinfo page:

Code:
<?php
phpinfo();
?>
While using PHP compiled with phpsuexec, you should see in the Configure Command section a portion that says "--prefix=/usr". I cannot be 100% sure, but I think all phpsuexec compiles will show this and place the CGI PHP binary in /usr/bin. If the prefix option shows /usr then it means it is using the /usr/bin/php binary and not the /usr/local/bin/php binary.

However, if you are having trouble showing PHP pages with phpsuexec enabled, then this may prove to be difficult. PHP compiled as an Apache module will not show a --prefix option, instead it will probably show a --with-apxs option.

If you continue to have problems, the best solution would be to look in the Apache error logs, probably in /usr/local/apache/logs/error_log or the suexec logs, /usr/local/apache/logs/suexec_log which might lead you in a better direction.
 

jackie46

BANNED
Jul 25, 2005
536
0
166
Thanks for the reply.

I seriously believe there is an issue with /scripts/easyapache and the way its building php.

I have phpsuexec running on 9 boxes and it was installed 4 weeks ago. Every box runs flawlessly. I would suspect that the buildapache.sea 4 weeks ago did not have an issue whereas when i try to install phpsuexec on a RHEL 3 server, purchased 2 days ago mind you. the binaries are placed in the wrong directory so when our php sites try to access the php installation they all get the dreaded 500 because they are trying to access a CLI build version of php instead of a CGI version which is in /usr/bin/

Problem being of course is that it is impossible to view a phpinfo.php file. I have recompiled the entire box 9 times since 5pm yesterday. Every single time WHICH PHP shows that the binary is in /usr/local/bin/php when it should be in /usr/bin/php. I even tried to trick it by creating a symlink php -> /usr/bin/php and that did not work. I wonder why?

I also tried recompiling and going down a version to 4.3.10. Not only did that not work but this version is VULN! So why would i want to? Anyway, that did not work.

This box is the box from hell. It came installed with Perl 5.8.0. Needless to say, after running the perl587installer the installation complains with WHOA! errors all thoughout the installation. Just another one of those days.

Looked though suexec_log. Nothing obvious other than a few error dealing with being unable to stat etc but rightfully so, since PHP in dead in the water when phpsexec is installed.

I wonder how many others are having this issue with the currently buildapache.sea.

I would specify prefix if i could find out where they are specifying this during the compile.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,021
226
368
cPanel Access Level
Root Administrator
I don't think its really an issue with what php path is being showed with which.

The command which just searches through your shell PATH variable and looks for binaries that match. If you run which with no options it will just return the first match.

If you type:

Code:
echo $PATH
it will show you the current paths that your shell will search for executables, separated by colons. You will probably see that /usr/local/bin is listed before /usr/bin. When you type:

Code:
which php
The command will search through those PATH directories one at a time in order that they are displayed from echoing the $PATH variable. When it finds a php binary in /usr/local/bin it just returns that. You can also run:

Code:
which --all php
This tells the which command to not stop when it finds an entry and to parse through all of the PATH directories. If you do have a php binary in /usr/bin then it will be showed here.

I don't think this an issue because, if PHP is compiled with --prefix=/usr then that is just telling the server to use the PHP binary at /usr/bin/php. This should be a CGI compiled PHP binary. If running:

Code:
/usr/bin/php -v
shows it to be a CGI binary instead of a CLI, then this should not be causing problems. I cannot be certain that easyapache will compile the PHP CGI binary in /usr/bin. If you run easyapache from the command line (or maybe through the WHM) it might show the configuration line that it is using. You may have to select "Be Verbose" or whatever that option is in easyapache. I cannot be certain, it has been a while since I have run easyapache and I have never really paid that much attention to the options.
 

rhenderson

Well-Known Member
Apr 21, 2005
778
2
168
Oklahoma
cPanel Access Level
Root Administrator
This happens to me also

Using WHM to compile apache with phpsuexec..... I get

~# which php
/usr/local/bin/php

~# /usr/local/bin/php -v
PHP 5.0.4 (cli) (built: Sep 26 2005 15:05:15)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies
with Zend Extension Manager v1.0.8, Copyright (c) 2003-2005, by Zend Technologies
with Zend Optimizer v2.5.10, Copyright (c) 1998-2005, by Zend Technologies
So it should be cgi right?

Here is the cgi (Different path)
~# /usr/bin/php -v
PHP 5.0.4 (cgi) (built: Nov 6 2005 10:13:35)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies
with Zend Extension Manager v1.0.8, Copyright (c) 2003-2005, by Zend Technologies
with Zend Optimizer v2.5.10, Copyright (c) 1998-2005, by Zend Technologies
Now the problem comes when you try to access the site and get a 500 Error,
and the error log says permission denied blah blah

So you have to edit the httpd.conf because the /home/cpapachebuild/buildapache/phpsuexecmodconf does this;

Code:
regsrep("/usr/local/apache/conf/httpd.conf","LoadModule[\\s]*php4_module[\\s]*libexec/libphp4.so$
regsrep("/usr/local/apache/conf/httpd.conf","AddModule[\\s]*mod_php4.c","#AddModule mod_php4.c");
regsrep("/usr/local/apache/conf/httpd.conf","LoadModule[\\s]*php5_module[\\s]*libexec/libphp5.so$
regsrep("/usr/local/apache/conf/httpd.conf","AddModule[\\s]*mod_php5.c","#AddModule mod_php5.c");
remove # for lines it comments out (which on depends on the version of
php you are running) save it restart apache and the sites work again.
PHP is going to the path for the CLI and the modules are commented
out because you compiled with phpsuexec and it sets the httpd.conf
to run the cgi, so the result is error 500.

I have not editted any of the scripts to change paths, I have let WHM
build apache everytime. **HOWEVER** I do not think this problem
occured until I compiled with phpsuexec and then wanted to remove
it so I rebuilt apache and unchecked phpsuexec then the problems started.

I have no ideal why it does this, but sounds to me like it is same problem
as above. So I have to assume since apache builds, compiles etc.. the php
then it sets the path. Right? If it does then why does it set it wrong on our
server? By adding phpsuexec support then later removing breaks the build
process so you have to manually edit the httpd.conf?

Secondly, since it is like this running as CLI not matter how many times
I compile it the path will not change, so basically I am running without
phpsuexec? Lol it does enforce directory permissions.

It is confusing can anyone shed some light on this?

Thanks
 
Last edited:

rhenderson

Well-Known Member
Apr 21, 2005
778
2
168
Oklahoma
cPanel Access Level
Root Administrator
It can't be running as both. You either run php as a module or comment out the module loads in httpd.conf and run php as CGI as phpsuexec. I use phpsuexec on all my servers and they're all running v4.4.1 without problems.
But heres the deal, I copile apache with phpsuexec ticked and it does comment out the load modules in 2 places for PHP5 which is right, but I get server 500 errors, I uncomment the lines and the sites load. Which leads me to believe it must not be running as CGI right?
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,453
31
473
Go on, have a guess
No, that would be because you have script problems, probably due to incorect directory/file permissions because of the restrictions inposed by using phpsuexec. You should check both the apache error_log and suexec_log for the reasons you're getting 500 errors.
 

rhenderson

Well-Known Member
Apr 21, 2005
778
2
168
Oklahoma
cPanel Access Level
Root Administrator
chirpy said:
No, that would be because you have script problems, probably due to incorect directory/file permissions because of the restrictions inposed by using phpsuexec. You should check both the apache error_log and suexec_log for the reasons you're getting 500 errors.
I appreciate your comments, hopefully you can help me understand this.

The error logs says permission denied, and it was not a script, plain HTML index file when you load the site. Uncommenting the modules for PHP5 restores the site to work. The permissions are public_html folder 750 and the index.html file is 0644.

It sounds like your saying if it compiled both ways it will work as CGI if the modules are commented out and as a module if they are not commented out automatically. How does apache know which directrory to access /usr/bin or /usr/local/bin I am sure that is defined somewhere.

Now the strange thing is that in some respects with the modules active (which all I read said phpsuexec must be ran with php as a cgi) phpsuexec stills does work to the exent of not allowing 777 folders (my understanding is this is a phpsuexec protection).

I would rather have the full effect of phpsuexec in case of a future spammer signs up for the service so I can track where it is coming from.

Thanks
Randy
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,453
31
473
Go on, have a guess
The binary that php uses when run in CGI for phpsuexec is set during compile time of apache in /home/cpapachebuild/buildapache/apache_1.3.34-php-suexec-patch:

#define PHP4HANDLER "/usr/bin/php"

One effective way of ensuring correct directory and file permissions is to use:

/scripts/chownpublichtmls

If you're having problems browsing any pages in a site (and get 500 errors) then you probably have php settings in a local .htaccess file. This are incompatible with phpsuexec and have to be removed and then added to a local php.ini file instead.
 

rhenderson

Well-Known Member
Apr 21, 2005
778
2
168
Oklahoma
cPanel Access Level
Root Administrator
chirpy said:
The binary that php uses when run in CGI for phpsuexec is set during compile time of apache in /home/cpapachebuild/buildapache/apache_1.3.34-php-suexec-patch:

#define PHP4HANDLER "/usr/bin/php"

One effective way of ensuring correct directory and file permissions is to use:

/scripts/chownpublichtmls

If you're having problems browsing any pages in a site (and get 500 errors) then you probably have php settings in a local .htaccess file. This are incompatible with phpsuexec and have to be removed and then added to a local php.ini file instead.
Ah Ha, very good there's where the problem comes in. Since we are running PHP5 and PHP4 (as a cgi) we use .htaccess files to be able to define which one we want on a folder basis. Since we are doing that then it sounds like we should disable phpsuexec. So when we do and recompile apache then go to the web site index.php apache does not know how to handle .php so it tries to let you "download" the file. I assume when we compile without phpsuexec it removes or comments out one of our handler lines in the https.conf

So we will need to compare before and after we compile to determine which line it changes.

Regards
 

rhenderson

Well-Known Member
Apr 21, 2005
778
2
168
Oklahoma
cPanel Access Level
Root Administrator
Contents of /home/cpapachebuild/buildapache/apache_1.3.34-php-suexec-patch
Code:
+#ifdef INCLUDEPHP
+#define PHP3HANDLER "/usr/bin/php"
+#define PHP4HANDLER "/usr/bin/php"
+#define PHP3 3
+#define PHP4 4
+#define PHP3TYPE "application/x-httpd-php3"
+#define PHP4TYPE "application/x-httpd-php"
+#endif
But what about php5?