4

I have a D7 site. I start getting a 500 internal server error. I get the default Chrome (my browser) error page, instead of the one from my server.

This error occurs only after I log in and have navigated through a page or two. The apache error log shows nothing except for the following message : 

[Sun Jul 15 21:53:27 2012] [debug] mod_deflate.c(615): [client 127.0.0.1] Zlib: Compressed 0 to 8 : URL /php5-fcgi/index.php, referer: http://new.whack.co.in/admin/modules

I can browse through the whole site anonymously without encountering any problems. I can even access the site temporarily by clearing my browser's cache.

The site uses a combination of Varnish+Apache 2+APC+php-fpm+memcache. I have a D6 site installed on the same server and I can navigate through it without encountering any problems.

This site was installed by using Drush Site Upgrade. Contents and settings were migrated from a the previously mentioned D6 site. The D6 site is stored on /var/www/drupal (Accesible from default domain) while the D7 site on /var/www/seven - (accessible from a subdomain).

What can be the possible cause of the problem and how can I fix it? Please do let me know if any other information is required.

Improve this question

3 Answers 3

Reset to default
4

From my research there are basically four things that could cause the '500 internal server error' with drupal :

  1. Misconfgured server (you will have to dig into your server configs)
  2. Misconfigured .htaccess file (replace your existing .htaccess with the drupal default)
  3. Misconfigured file permissions
  4. Low php memory_limit setting

In my case, the culprit was the memory_limit setting. After doubling the same, my site is flying right now.

Improve this answer
2
  • The system does not allow me accept my own answers for two days. So will have to wait till then. Thanks for the tip though.
    – bcosynot
    Commented Jul 16, 2012 at 9:33
  • on PHP5 the file to edit is (for me) /etc/php5/apache2/php.ini and look for "memory_limit" -- for PHP7 it's /etc/php/7.0/apache2/php.ini -- and do not forget to restart Apache afterward: /etc/init.d/apache2 restart
    – seizethecarp
    Commented Feb 12, 2018 at 20:58
1

I would like to add 5. to the above list. This catches me up when I configure the base URL in settings.php and forget to alter it after I migrate to a live server. Check to see the base url and that the domain configuration for caching is correct. Maybe use a default settings.php file with correct db settings and see if that helps.

Improve this answer
0

Another possible cause: a module which produces different results depending on logged in / logged out state. This is esp. probable if some types of pages are still accessible, while others are not.

In my specific case, there was a bug in a Drupal Commons 7.x-3.2 view called "Commons Activity Streams - Activity (Site-wide)". When removing it, or switching it from the "Activity - Full view" display to "Activity (Sidebar)", all pages worked fine again.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.