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.

empty php.ini fixes issues?!

Discussion in 'General Discussion' started by PsyberMind, Oct 16, 2011.

  1. PsyberMind

    PsyberMind Member

    Joined:
    Apr 7, 2010
    Messages:
    8
    Likes Received:
    0
    Trophy Points:
    1
    Ok, I can't wrap my brain around this one at all..

    We have a VPS running suPHP. Everything is correct as far as I can tell. Here's where it gets weird

    Fist of all, phpinfo comes back with "an error occurred while processing this directive"

    Error_log: [error] [client xx.xx.xx.xx] exec used but not allowed in /home/USERNAME/public_html/500.shtml

    Now, if we place a BLANK php.ini in the directory, phpinfo works fine.

    So we are in the site itself now.. Wordpress install. The CSS Won't load, same error (so I think that the 500.shtml error is unrelated) we place a blank php.ini in the wp_content directory, and the theme directory, and it all loads..

    Since when does an empty php.ini fix an issue like this?
     
  2. Brian

    Brian Well-Known Member

    Joined:
    Dec 1, 2010
    Messages:
    117
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Texas
    cPanel Access Level:
    Root Administrator
    When running suPHP, php.ini files behave in a very specific way. Essentially, if a php.ini file exists then PHP's defaults (not your server's defaults, but the PHP's actual default configurations) are utilized.

    This means that a blank php.ini, while using suPHP, is tantamount to setting PHP defaults across the board as described here: PHP: List of php.ini directives - Manual

    This is why when creating custom php.ini files, while using suPHP, it's critical to first copy the server's default php.ini and then make your modifications from there to ensure that you're only changing what you want to change.

    Circling back, this then means that if a blank php.ini is resolving the situation for you, then some custom php.ini configuration is causing the break for you. Setting your php.ini values to all defaults (via an empty php.ini) effectively "resolves" the problem.

    The issue now is to determine what specific php.ini setting is causing this for you.

    The error you've pasted:
    Code:
    [error] [client xx.xx.xx.xx] exec used but not allowed in /home/USERNAME/public_html/500.shtml
    doesn't really sound like the relevant error you should be looking at. To me, that's not the actual PHP error. Instead, that sounds like a 500 internal server error was served, and that coincidentally an error was encountered when trying to serve the custom 500 page (500.shtml) because Includes and/or ExecCGI is off. You could "solve" the error you've posted by turning on Includes / ExecCGI in .htaccess for the user, but that's not going to solve whatever origin PHP error you're experiencing.

    What are the line(s) above the one you've posted? Generally you're going to see the error that *caused* to 500 internal server error followed by any errors generated when trying to display the 500 internal server error. The latter seems to be what you've posted.

    Does this help explain the situation?

    The next advised step would thus be to associate the PHP problem with the actual error in the error_log (Apache or PHP error_log) to help determine what custom php.ini setting is causing the origin problem for you. The empty php.ini isn't going to be the proper solution here, but it does prove that some custom php.ini setting (or module) is at fault.
     
  3. PsyberMind

    PsyberMind Member

    Joined:
    Apr 7, 2010
    Messages:
    8
    Likes Received:
    0
    Trophy Points:
    1
    The only change I made to the php.ini was to increase the memory limit, timeout and script execution time. The only thing I can think of that would cause the problem is that I left off the M at the end of the memory limit declaration. Let me put that in there, and see if that makes a difference..

    Because the site was working prior to that adjustment...
     
  4. PsyberMind

    PsyberMind Member

    Joined:
    Apr 7, 2010
    Messages:
    8
    Likes Received:
    0
    Trophy Points:
    1
    You got to be kidding me.. a single little M did the trick? Wow... thanks for the heads up
     
  5. Brian

    Brian Well-Known Member

    Joined:
    Dec 1, 2010
    Messages:
    117
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Texas
    cPanel Access Level:
    Root Administrator
    Providing the shorthand for megabytes with memory_limit is critical, as otherwise the limit is something vastly different.

    memory_limit = 32
    would signify 32 bytes, which is about .00003MB

    Vastly different than:

    memory_limit = 32M
    which would signify 32MB.

    Valid notation is: nothing (bytes), K (kilobytes), M (megabytes), G (gigabytes).

    It would definitely make sense if your memory_limit was in bytes and the value was something quite small that lots of problems would crop up from unusually low memory constraints.
     
Loading...

Share This Page