Redirect if database is unavailble [#9316]

It seems maybe once or twice a month that I run into this error and it is the only thing visible to me or anyone else who visits my site:

Warning: mysql_connect(): Too many connections in /home/public_html/drumbeat/includes/database.mysql.inc on line 12
Too many connections

After searching online I found it's the MySQL server that's getting too many connections. There could be 300 other sites on that server also all utilizing MySQL and bogging it down, not specifically my site.

Since this situation is out of my control, well out of our control as drupal site owners, I suggest we check for this error and send them to another page. I found on a solution to show an alternative page taken from the MySQL site http://www-fr.mysql.com/doc/en/Too_many_connections.html.

$link = mysql_connect("localhost", "mysql_user", "mysql_password");
if (mysql_errno() == 1203) {
  // 1203 == ER_TOO_MANY_USER_CONNECTIONS (mysqld_error.h)
  header("Location: http://your.site.com/alternate_page.php");
  exit;
}

The alternative page could be defined in the conf.php file. Someone else will have to figure out where to put this code. I'm not that good at drupal yet to know where to put this code and I'm not that good at cvs yet to generate a patch yet. (I'm getting there!)

Comment	File	Size	Author
#10	service_unavailable2.patch	6.46 KB	jhriggs
#2	service_unavailable.jpg	18.46 KB	jhriggs
#1	service_unavailable.patch	6.79 KB	jhriggs

Comments

Comment #1

jhriggs commented 16 July 2004 at 01:46

Component:	database system	» base system
Category:	bug	» feature

Status	File	Size
new	service_unavailable.patch	6.79 KB

This certainly won't be fixed for 4.4, and it is a feature request rather than a bug. Adjusting settings appropriately...

Here is a patch that implements this, albeit using a slightly different approach:

Added new function drupal_service_unavailable($error, $message) to bootstrap.inc that is designed to return an HTTP 503 (Service Unavailable) error code. This function should be used for extremely critical, unrecoverable errors, such as being unable to connect to the database. It returns either a very Apache-like error page by default, or the page specified by the variable described below. This allows for a much more elegant solution than the current calls to die(), and it also allows the site admin to customize the behavior of such fatal errors (to some extent).
Added $fatal_error_page variable to the site configuration file for use in drupal_service_unavailable(). An empty string (or a file that does not exist) results in the built-in page being used.
Updated database.mysql.inc and database.pear.inc to use drupal_service_unavailable() instead of die().
Defined constant DRUPAL_VERSION in bootstrap.inc for use in drupal_service_unavailable(). (I think this can also be useful elsewhere.)
Updated conf.php to use single quotes.

Comment #2

jhriggs commented 16 July 2004 at 01:47

Status	File	Size
new	service_unavailable.jpg	18.46 KB

A screen shot of the Apache-like default page...

Comment #3

judah commented 16 July 2004 at 02:43

This looks like it will fix the issues. Thank you. I like the drupal version constant. I can see some places right away where it would be useful. I have a couple of drupal sites and I can't always remember what site is running what version. Having a page (configuration page?) show the version number will make that easy to find out.

Comment #4

duztin commented 19 July 2004 at 21:59

I tried to apply this patch for version 4.4.1 with no luck anyone know how to fix the problem?

Comment #5

jhriggs commented 19 July 2004 at 22:33

The patch is for CVS HEAD.

Comment #6

jonbob commented 23 July 2004 at 15:58

The Drupal version constant would be wonderful to have. It would be even nicer if that could be generated by CVS, so we'd know the "marketing name" as well as more granular CVS-based version numbers.

Comment #7

(not verified) commented 23 July 2004 at 16:33

I've wanted this Drupal version constant for about a year. Unfortunately, because CVS supplies no keyword which will expand into a tag, unlike the $Id$ or $Revision$ keywords, the only way to make this happen is by hand.

CVS maintainers who tag or label a release of Drupal MUST update the internal constant value. With this patch, that would mean editing the string in the define for DRUPAL_VERSION in bootstrap.inc.

Is that the best way to do this?

I would envision using DRUPAL_VERSION as well as a PHP variable defined like this: $cvs_id = '$Id$' as part of both the auto-install and configuration, as a way to check compatibilty when installing or enabling modules ("warning: this module requires DRUPAL-4-5 and your version is DRUPAL_VERSION"), or as part of an automated info dump for bug reporting ("www.foo.bar is running Drupal version DRUPAL_VERSION and foo.module revision $cvs_id").

I actually had most of an XML-RPC bug/error reporting system built using the $cvs_id idea, but accidentally deleted the files. =-b

Comment #8

dries commented 26 July 2004 at 19:34

The information line at the bottom of the error page (see screenshot) is actually pretty redundant: it offers the user little or no information.
Why do we want to configure the fatal error page through conf.php? What is wrong with using a built-in default?

I'm OK with the patch (sending a proper header is good) but I'd like to simplify the patch by removing the abovementioned issues. Less is more.

Comment #9

jhriggs commented 26 July 2004 at 19:50

WRT point 1: I have no problem with removing the informational line with server information. I specifically made it look just like Apache's built-in error pages, but this is certainly not a necessity for this patch.

WRT point 2: It has a built-in default (that shown in the screenshot). If the site admin wants to handle the error in some customized way (displaying a "site maintainance" page with a look similar to that of the site, for example), he can set this variable to point to the HTML file to be used.

Comment #10

jhriggs commented 6 August 2004 at 13:26

Status	File	Size
new	service_unavailable2.patch	6.46 KB

Here is an updated patch. It removes that "information line" in the default page. I left the conf variable $fatal_error_page though, as the original request was for the ability to display a custom page, and I think it is quite useful from an admin standpoint (though many users may not need it).