The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

All of a sudden 500 server error

Discussion in 'General Discussion' started by jackie46, Oct 12, 2005.

  1. jackie46

    jackie46 BANNED

    Joined:
    Jul 25, 2005
    Messages:
    537
    Likes Received:
    0
    Trophy Points:
    0
    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:
     
  2. jackie46

    jackie46 BANNED

    Joined:
    Jul 25, 2005
    Messages:
    537
    Likes Received:
    0
    Trophy Points:
    0
    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?
     
    #2 jackie46, Oct 12, 2005
    Last edited: Oct 12, 2005
  3. gorilla

    gorilla Well-Known Member

    Joined:
    Feb 3, 2004
    Messages:
    699
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Sydney / Australia
  4. jackie46

    jackie46 BANNED

    Joined:
    Jul 25, 2005
    Messages:
    537
    Likes Received:
    0
    Trophy Points:
    0
  5. sparek-3

    sparek-3 Well-Known Member

    Joined:
    Aug 10, 2002
    Messages:
    1,381
    Likes Received:
    23
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    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.
     
  6. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    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.
     
  7. jackie46

    jackie46 BANNED

    Joined:
    Jul 25, 2005
    Messages:
    537
    Likes Received:
    0
    Trophy Points:
    0

    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.
     
  8. jackie46

    jackie46 BANNED

    Joined:
    Jul 25, 2005
    Messages:
    537
    Likes Received:
    0
    Trophy Points:
    0

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

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    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.
     
  10. sparek-3

    sparek-3 Well-Known Member

    Joined:
    Aug 10, 2002
    Messages:
    1,381
    Likes Received:
    23
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    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.
     
  11. jackie46

    jackie46 BANNED

    Joined:
    Jul 25, 2005
    Messages:
    537
    Likes Received:
    0
    Trophy Points:
    0
    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.
     
  12. sparek-3

    sparek-3 Well-Known Member

    Joined:
    Aug 10, 2002
    Messages:
    1,381
    Likes Received:
    23
    Trophy Points:
    38
    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.
     
  13. rhenderson

    rhenderson Well-Known Member

    Joined:
    Apr 21, 2005
    Messages:
    785
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Oklahoma
    cPanel Access Level:
    Root Administrator
    This happens to me also

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

    So it should be cgi right?

    Here is the cgi (Different path)
    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
     
    #13 rhenderson, Nov 6, 2005
    Last edited: Nov 6, 2005
  14. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
  15. rhenderson

    rhenderson Well-Known Member

    Joined:
    Apr 21, 2005
    Messages:
    785
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Oklahoma
    cPanel Access Level:
    Root Administrator
    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?
     
  16. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    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.
     
  17. rhenderson

    rhenderson Well-Known Member

    Joined:
    Apr 21, 2005
    Messages:
    785
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Oklahoma
    cPanel Access Level:
    Root Administrator
    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
     
  18. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    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.
     
  19. rhenderson

    rhenderson Well-Known Member

    Joined:
    Apr 21, 2005
    Messages:
    785
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Oklahoma
    cPanel Access Level:
    Root Administrator
    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
     
  20. rhenderson

    rhenderson Well-Known Member

    Joined:
    Apr 21, 2005
    Messages:
    785
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    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?
     
Loading...

Share This Page