diff options
| author | friendica <info@friendica.com> | 2013-10-04 14:42:18 -0700 |
|---|---|---|
| committer | friendica <info@friendica.com> | 2013-10-04 14:42:18 -0700 |
| commit | e369e5ddc53e6a0d489ceaed0bd13849c7d031f1 (patch) | |
| tree | b65d913f6b25489f29b7e83cf73d10f44e2d16d7 /include | |
| parent | ff7182f441907065b852b24cbf86547752a9b9ad (diff) | |
| download | volse-hubzilla-e369e5ddc53e6a0d489ceaed0bd13849c7d031f1.tar.gz volse-hubzilla-e369e5ddc53e6a0d489ceaed0bd13849c7d031f1.tar.bz2 volse-hubzilla-e369e5ddc53e6a0d489ceaed0bd13849c7d031f1.zip | |
The check for f*cked database (which otherwise sends out zillions of update failed emails) interferes with install. So what else can we do about f*cked databases which open successfully but don't actually read/write data? It would of course be nice if we didn't have to deal with them, but apparently we do. For now we're not doing anything until I can figure out how to take the site offline when it happens without affecting install.
Diffstat (limited to 'include')
| -rw-r--r-- | include/config.php | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/include/config.php b/include/config.php index ccd907424..bccf0737f 100644 --- a/include/config.php +++ b/include/config.php @@ -29,9 +29,9 @@ function load_config($family) { // If the DB was successfully opened, but we can't read from it, // we must assume catastrophic failure of the DB. Report the system down. - if($r === false) { - system_unavailable(); - } +// if($r === false) { +// system_unavailable(); +// } if($r !== false) { if($r) { |