[solved] 500 Errors - Request Timeout

[craigles]

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??

 

[NiteWave]

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

 

[craigles]

Hi,

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.

 

[webizen]

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

...

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?

<?php echo "hello world" ?>

 

[craigles]

Hi,

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.

 

[webizen]

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.

 

[craigles]

Hi,

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.

 

[webizen]

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

 

[craigles]

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

 

[NiteWave]

when PHP_INI_SCAN_DIR set, /home/xxxx/public_html/phpCopy.ini is read.
comment out this line in phpCopy.ini
/usr/local/Zend/lib/Guard-5.5.0/php-5.3.x/ZendGuardLoader.so
phpinfo() works fine. and looks the whole site works too.
so still this ZendGuardLoader.so issue.

 

[craigles]

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.

Cheers.