aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorfriendica <info@friendica.com>2013-10-04 14:42:18 -0700
committerfriendica <info@friendica.com>2013-10-04 14:42:18 -0700
commite369e5ddc53e6a0d489ceaed0bd13849c7d031f1 (patch)
treeb65d913f6b25489f29b7e83cf73d10f44e2d16d7
parentff7182f441907065b852b24cbf86547752a9b9ad (diff)
downloadvolse-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.
-rw-r--r--include/config.php6
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) {