[solved] 500 Errors - Request Timeout

Discussion in 'Install/Configuration' started by craigles, Mar 7, 2012.

  1. craigles

    craigles Active Member

    Hi Everyone,

    Have an issue with one account on our servers.
    If you try and bring up the site with LS enabled, it simply stalls and delivers this message:

    Request Timeout

    This request takes too long to process, it is timed out by the server. If it should not be timed out, please contact administrator of this web site to increase 'Connection Timeout'.

    I've tried everything, including removing the php.ini and .htaccess and making sure permissions are fine on the account - but to no avail.

    Switching back to Apache resolves the issue and the account loads without issue.

    Can anybody recommend what I might be able to do to get this account working??
    Last edited by a moderator: Mar 9, 2012
  2. NiteWave

    NiteWave Administrator

    have you built matching php ? compare phpinfo() under litespeed and apache, to be sure first they matches.
  3. craigles

    craigles Active Member


    Yes I have built the matching PHP - plus I have also enabled the easyapache hook and recompiled again just to make sure.

    Unfortunately it's impossible to compare the phpinfo output from both, because nothing will load from that account when Litespeed is activated.

    However, using another account and comparing both outputs from apache and litespeed reveal no differences that I was able to see.
  4. webizen

    webizen Well-Known Member

    If not mistaken, the issue is only for this particular account. Other accounts are OK. Do you have any per user php.ini setup, etc? how about a simple index.php like the following?
  5. craigles

    craigles Active Member


    Correct - the issue appears to be only related to this account for whatever reason. Nobody else has reported an issue on the server / I haven't been able to find anyone else.

    We do have a per user php.ini setup, with the PHP_INI_SCAN_DIR setup.

    Even a simple file such as you have recommend does absolutely nothing - it times right out.

    I've tried ditching the php.ini and the .htaccess just to make sure there wasn't something dodgy in there but to no avail at all.
  6. webizen

    webizen Well-Known Member

    is it possible to remove its per user php.ini and use the global php.ini to see any difference? if no difference, pm server temporary root access for us to look into if you would like.
  7. craigles

    craigles Active Member


    Already tried that - removed both their per user php.ini from public_html as well as the .htaccess file just in case it was causing grief.

    I've been talking with NiteWave and he has been looking at it for me :) But thanks for the offer, very kind indeed.
  8. webizen

    webizen Well-Known Member

    you are welcome. just to make sure the issue is being looked into.
  9. craigles

    craigles Active Member

    Thankyou so much guys for all your assistance - very much appreciated.

    NiteWave figured out what the problem was - we are using PHP_INI_SCAN_DIR and I didn't even realise it would read in every file ending in a .ini

    And I was making backup copies of the php.ini and leaving them with a .ini entry.

    Silly me.

    Anyway thanks once again guys :)
  10. NiteWave

    NiteWave Administrator

    when PHP_INI_SCAN_DIR set, /home/xxxx/public_html/phpCopy.ini is read.
    comment out this line in phpCopy.ini
    phpinfo() works fine. and looks the whole site works too.
    so still this ZendGuardLoader.so issue.
    Last edited: Mar 9, 2012
  11. craigles

    craigles Active Member

    Has there been any feedback on the issue with the ZendGuardLoader.so bug that you guys apparently made a post about??

    A few of our users use this, so it would be nice to be able to offer it to them.


Share This Page