500 error out of the blue

Permalink 2 users found helpful
I've built this site a few months ago, everything was running fine, until 2 days ago my client told me the site is down. Neither he or myself has made any changes in the last month.

Not sure what has causes the break down. Tried searching in the forum and tried other people's solutions and none of them work for me yet.

-Going to domain-name.com/index.php/dashboard gives 500 error.
-Saw some thread saying it may be a cache issue. But I have no way of going into c5 to clear it.
-Page loads on domain-name.com/index.php/tools/upgrade/, but when try to run update, error occurs. "An Unexpected Error occured while upgrading: mysql error: [1142: INDEX command denied to user 'admin'@'localhost' for table 'PermissionAssignments'] in EXECUTE("DROP INDEX pdID ON PermissionAssignments")"

Not sure what had happened and what I can do to fix it.

 
tallacman replied on at Permalink Reply
tallacman
Do you have a public url we can see?
szewaili replied on at Permalink Reply
http://www.agelessideas.com/index.php

FYI: I have currently removed .htaccess. So, it's going to my index.html fall back page by default.

Also, I see in my error_log it's logging this "PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0" since Oct 31. I guess that's when the site is down, perhaps?
ScottSandbakken replied on at Permalink Reply
ScottSandbakken
You can force Concrete5 to rebuild its cache by deleting the [root]\files\cache folder.

The error I am seeing in FireBug is "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must to be declared in the document or in the transfer protocol."

Also, you say that you removed your .htaccess file. Did this help? Did you make changes to it that you think may be causing this issue?
szewaili replied on at Permalink Reply
I just tried deleting the cache folder to force c5 to rebuild. no success.

The removal of the .htaccess isn't helping. It's still showing 500 error.

In firebug, I see the character encoding error as well. but the 500 error goes before that. I don't get how it gets a 500 error and then encoding error. Perhaps it's the error page that gives the encoding error.

So, it's still giving me this 500 error and I still don't know what had happened and caused it.

Any other input will be greatly appreciated.
ScottSandbakken replied on at Permalink Reply
ScottSandbakken
FTP into your server and rename the [root]\config\site.php file to site.old. DO NOT DELETE THIS FILE AS IT CONTAINS YOUR DATABASE INFORMATION AND SITE SETTINGS!

Once you have done this, go to your site and see if you get the install screen. DO NOT DO THE INSTALLATION! If you get the install screen, check that all the checks are green. This will tell you if your server is configured correctly. Once you have checked this rename the site.old file back to site.php.
szewaili replied on at Permalink Reply
Hmmm... Just tried that. Everything seems to check out fine except one optional item: Version Comparison Available. Since it's optional, it shouldn't matter. But I made it turned green anyway for the sake of trying.

Yet, no success. I wonder if it could be db corrupted? how do we test for that? I went to the db yesterday, following some thread from the forum, and see that maybe I have open tables? what does that mean?
ScottSandbakken replied on at Permalink Reply
ScottSandbakken
Well, the point of that was to verify that your server was working.

Next test, in the [root]\config\site.php file, look for the line that reads
define('DB_PASSWORD', 'xxxxxxxx');

and add an exclamation point to the end of the password. We want to break the database connection to see if we get a "Unable to connect to database" error message.

Assuming you get a database connect error, go back into the site.php file and remove the exclamation point you added, then comment out anything that doesn't have to do with the database connection or the password salt and try your site again. Post any message you receive here.
ScottSandbakken replied on at Permalink Reply
ScottSandbakken
Also, if you have anything in the site.php file that references a Concrete5 version number, post that line.
szewaili replied on at Permalink Reply
Ok. I just tried adding the password with "!" and it does return an "Unable to connect to database." message.

The rest of the lines in the site.php file are as follow, nothing that doesn't have to do with database or password salt:

<?php
define('DB_SERVER', 'XXX');
define('DB_USERNAME', 'XXX');
define('DB_PASSWORD', 'XXX!');
define('DB_DATABASE', 'XXX');
define('PASSWORD_SALT', 'XXX');?>
<?php define('DIRNAME_APP_UPDATED', 'concrete5.6.0.2');?>

Nothing looks out of ordinary in my understanding.

Does this mean the db is corrupted?
ScottSandbakken replied on at Permalink Reply
ScottSandbakken
Before trying anything in my last post, comment out the
<?php define('DIRNAME_APP_UPDATED', 'concrete5.6.0.2');?>
line and try your site. This will force Concrete5 to use the older core files (before your last update).
szewaili replied on at Permalink Reply
Interestingly, when I comment out the line <?php define('DIRNAME_APP_UPDATED', 'concrete5.6.0.2');?>, after a little bit of waiting, the site is back!

Does this mean the someone had tried to do an update and failed?
ScottSandbakken replied on at Permalink Reply
ScottSandbakken
The update may not have failed, but something in the update is preventing your site from working.

My recommendation is to create a sandbox site to retry the update on. Then do your trouble shooting there.
ScottSandbakken replied on at Permalink Reply
ScottSandbakken
If commenting out everything but the database connection does not restore your site, remove the comments you added to the site.php file.

At this point, we have established that your server can support Concrete5 and that it believes it is able to connect to the database. The next step is to give it a new database to see if it is a database issue. Ideally, we would create a new database from one of your backups and modify the site.php file (make sure you keep a backup) to point to this restored database (make sure you do not overwrite your existing database). If the site returns, you likely have a database issue.

If you do not have a backup of your database, you can rename the site.php file to site.old as we did at the beginning. Then, create a new database and run the Concrete5 installation on this new database. If you are able to install Concrete5, you likely have database issues. If not, post the error message.
ScottSandbakken replied on at Permalink Reply
ScottSandbakken
Did you get everything worked out?
szewaili replied on at Permalink Reply
I've currently just removed the line <?php define('DIRNAME_APP_UPDATED','concrete5.6.0.2');?> as a temporary fix for my client. (at least his site is showing up with that line removed.)

I have not yet found time to create a separate site and db to test it. I'll most likely do that tonight or the next couple of days. And will try to do an update to see whether it's the update that messes up the db or not.

I'll keep you posted. Thank you for checking in! Really appreciate your support!
I'll keep you updated about my progress.
nypcsinc replied on at Permalink Reply
Hello. I have the same issue. and internal 500 error. My site provider has told me the following things but I am not sure how to optimize the site. ANY ideas would be appreciated.

The first regarding not being able to apply a process slot, this is caused by your website reaching the max concurrent processes allowed to be ran at once. This can be caused from a number of different issues such as coding in the website attempting to load/parse data from other php files on the site. In general, I would suggest using require() or include() within your website coding for loading resources in other php files instead of the file_get_contents() function. This will help resolve this matter with the index page loading.

Regarding the other error mentioned for read data timeouts, this can very well be caused by process slot error as data is not completely being loaded from your website. I currently show your index.php page is the only which does not load directly however subdirectories are indeed available through your browser.

Can you please review your website and coding to see if there are excessive amounts of resources being loaded through php files please?
------------------
Mon Jul 08 10:55:56 2013] [warn] [client 86.124.179.232] mod_fcgid: read data timeout in 70 seconds
[Mon Jul 08 10:55:56 2013] [error] [client 86.124.179.232] Premature end of script headers: index.php

------------------

ANY HELP WOULD BE GREATLY APPRECIATED.