We're working on a community collection initiative using Omeka (http://www.worldtreeproject.org/). Every so often we will come to the site, and find a notice that Omeka has installed successfully instead of the site. This usually lasts for about an hour or so before things start working normally again. It does not seem to relate to any specific actions on our part, as it occurs when we are inputting things and also just when we open the site up in a browser. Neither myself nor the other guy working on the project are website gurus, and we are just feeling our way forwards as we go at the moment, so we are a bit clueless. I've tried searching on here but not found anything similar (poss. wrong search terms). Any idea how we can stop this error happening?
This might also be a question for your hosting company or server admin, since it sounds like there might be an odd redirect.
It also seems possible that sometimes you arrive at
http://www.worldtreeproject.org/, and sometime at
http://www.worldtreeproject.org/install -- is that what you see in the URLs you get to?
Thank you for the quick response.
Yes, my colleague is speaking to the hosting company about this.
When the error occurs, www.worldtreeproject.org redirects to www.worldtreeproject.org/install and refuses to go to the main project website. Is this then a hosting issue?
Not sure yet where the issue might be. If there is a problem with Omeka seeing that the database is installed, I could imagine Omeka thinking that this is the first setup and redirecting there. However, if it really did not see the database as being set up with Omeka, I would have expected it to ask to install, rather than give the message that it is already installed.
Since it is sporadic, that makes me lean a little toward this being something with the database connection on the server side, but it could still be something else odd with Omeka in this particular installation.
Ok, thank you. We'll see what the host says as well and hopefully piece something together.
Hi, back again.
We contacted Dreamhost and asked them about the issue. They had us run a Traceroute and have looked at the site during an outage. They say they cannot see anything wrong at their end so we are no further forward. We did reach a point where the outages were down to 5 minutes at a time around 1pm each day, but it went out around 1pm today for an hour. Any advice or help with this would be very gratefully received. I've appended the trace below in case that is of use.
'Tracing route to worldtreeproject.org [188.8.131.52] over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms ccvss240.ucc.ie [184.108.40.206]
2 <1 ms <1 ms <1 ms uccasr2.ucc.ie [220.127.116.11]
3 5 ms 7 ms 7 ms te0-10-0-1-cr2-cwt.hea.net [18.104.22.168]
4 13 ms 13 ms 13 ms heanet-ias-geant-gw.lon.uk.geant.net [22.214.171.124
5 13 ms 13 ms 13 ms uk-hex.nordu.net [126.96.36.199]
6 * * * Request timed out.
7 15 ms 15 ms 15 ms ae10.mpr2.lhr2.uk.zip.zayo.com [188.8.131.52]
8 15 ms 15 ms 15 ms ae12.mpr3.lhr3.uk.zip.zayo.com [184.108.40.206]
9 90 ms 90 ms 90 ms ae27.cs1.lhr15.uk.eth.zayo.com [220.127.116.11]
10 90 ms 90 ms 94 ms ae5.cs1.dca2.us.eth.zayo.com [18.104.22.168]
11 88 ms 88 ms 88 ms ae27.cr1.dca2.us.zip.zayo.com [22.214.171.124]
12 90 ms 90 ms 90 ms ae15.er4.iad10.us.zip.zayo.com [126.96.36.199]
13 90 ms 90 ms 90 ms ae16.er5.iad10.us.zip.zayo.com [188.8.131.52]
14 89 ms 89 ms 89 ms 184.108.40.206.t00867-03.above.net [220.127.116.11
15 91 ms 91 ms 91 ms ip-208-113-156-4.dreamhost.com [18.104.22.168]
16 89 ms 90 ms 95 ms ip-208-113-156-73.dreamhost.com [22.214.171.124]
17 89 ms 89 ms 89 ms apache2-whippit.scorecard.dreamhost.com [173.236
I won't categorically rule out that there's an Omeka problem here, but I can't remember seeing anything quite like what you describe before.
The redirect to the install page happens when Omeka tries to read from the
options table and can't. Usually this means that Omeka hasn't been installed yet, so we redirect.
Some transient problem on the database server seems like a reasonable possibility, something causing an error when we try to read from that table. This is a little tough to diagnose, since Omeka doesn't really treat it as an error. The most helpful thing would probably be looking at the database during an outage and seeing what errors, if any, it's reporting.
Ok, thanks for that. I wondered if it might be a database problem but am not really tech savvy enough to be sure of myself in dealing with these things. I'll have a look and see what comes up.
The site is redirecting to the install page right now, but I am not seeing any error logs at all. How do I check the database for errors? Can I do that through the FTP client or do I need to log in to Dreamhost?
Probably the easiest thing for you to do is just make a small change to the Omeka code:
Change the word
false on line 20 of the file application/libraries/Omeka/Application/Resource/Options.php.
That change will make Omeka just report an error instead of trying to redirect to the installer. You can follow the regular directions for displaying errors to get a detailed error message that should shed light on what's happening.
Thank you. Yes, we're sorting out the error display so that we can get error logs. I'll try the change and see what we get. Much appreciate your help.
Hi there. Just to follow up RDale's post - we've changed Options.php to display the error message instead of the 'Omeka Installed' message, and we've followed the instructions for displaying errors, but no error is being logged apart from the redirect to the error message. Does this throw any light on the situation? The site is currently down, and seems to be down for between 15 mins and 90 mins every day at the same time. Thanks for all your help so far!
You said "no error is being logged apart from the redirect to the error message," what message there do you mean? The one about Omeka being installed, or a different one?
With that change to Options, you shouldn't be getting redirected at all, and you should be getting a different message than before.
Hi there - sorry, I didn't explain that very well.
We are getting a different screen being displayed when the website goes down (Omeka has encountered an error rather than the redirect to the install page), but there doesn't seem to be an error being logged. (Or at least, we have followed the instructions for activating error logs, but there is nothing in the errors.log file.) Thanks again - we really appreciate the help!
Have you tried the "Display Error Messages" option rather than the logging one from that page?
Normally anything that shows that kind of page is logged if you've got logging enabled... but this could be actually happening "too early," before the logger is set up, so nothing is logged.
When you're set to "display" errors, the same details that would otherwise be logged should just be displayed directly on the error page.
Thanks for the suggestion - we'll set that up for tomorrow and see what is displayed.
I've set up the site to display the error message on the page. We'll see what happens come lunchtime, and I'll get back to you with a report.
We've been asked if we have set up any cronjobs that might be interfering. We have not knowingly done so, but I wondered if Omeka had anything like that in its set-up?
Ok, we now have the error message. Does this make anything clearer?
Omeka has encountered an error
Mysqli statement execute error : Prepared statement needs to be re-prepared
'exception 'Zend_Db_Statement_Mysqli_Exception' with message 'Mysqli statement execute error : Prepared statement needs to be re-prepared' in /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Db/Statement/Mysqli.php:214
#0 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Db/Statement.php(303): Zend_Db_Statement_Mysqli->_execute(Array)
#1 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)
#2 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Db/Adapter/Abstract.php(811): Zend_Db_Adapter_Abstract->query('SELECT name, va...', Array)
#3 [internal function]: Zend_Db_Adapter_Abstract->fetchPairs('SELECT name, va...')
#4 /home/worldtreeproject/worldtreeproject.org/application/libraries/Omeka/Db.php(79): call_user_func_array(Array, Array)
#5 /home/worldtreeproject/worldtreeproject.org/application/libraries/Omeka/Application/Resource/Options.php(33): Omeka_Db->__call('fetchPairs', Array)
#6 /home/worldtreeproject/worldtreeproject.org/application/libraries/Omeka/Application/Resource/Options.php(33): Omeka_Db->fetchPairs('SELECT name, va...')
#7 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(695): Omeka_Application_Resource_Options->init()
#8 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(641): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource('Options')
#9 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(598): Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap('Options')
#10 /home/worldtreeproject/worldtreeproject.org/application/libraries/Omeka/Application/Resource/Pluginbroker.php(25): Zend_Application_Bootstrap_BootstrapAbstract->bootstrap('Options')
#11 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(695): Omeka_Application_Resource_Pluginbroker->init()
#12 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(641): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource('PluginBroker')
#13 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(598): Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap('PluginBroker')
#14 /home/worldtreeproject/worldtreeproject.org/application/libraries/Omeka/Application/Resource/Frontcontroller.php(59): Zend_Application_Bootstrap_BootstrapAbstract->bootstrap('PluginBroker')
#15 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(695): Omeka_Application_Resource_Frontcontroller->init()
#16 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(638): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource('frontcontroller')
#17 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(598): Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap(NULL)
#18 /home/worldtreeproject/worldtreeproject.org/application/libraries/Zend/Application.php(373): Zend_Application_Bootstrap_BootstrapAbstract->bootstrap(NULL)
#19 /home/worldtreeproject/worldtreeproject.org/application/libraries/Omeka/Application.php(51): Zend_Application->bootstrap()
#20 /home/worldtreeproject/worldtreeproject.org/index.php(23): Omeka_Application->initialize()
It sounds like it might be this MySQL issue. We've had people occasionally report this error, but it's hard to reproduce. The bug report indicates that it's sensitive to load on the server and to some server settings as well.
Since you say it happens at roughly the same time every day, I'd suspect that time is lining up with something like automatic periodic database backups that your host is performing.
This is definitely some better information you can go to your hosting company with, but I'm not sure they'll have much in the way of solutions other than upgrading to less-shared database hosting. It's possible that just moving to a different database server even of the same type would resolve the issue, though.
Yes, the site has not been under any undue load yet, so back-ups or something like that could be the issue. We've emailed the hosting company with these details too. With any luck they will have a fix. I did see, when googling the error report that changing some of the parameters in the database, might fix it. Let's see what the hosting company comes back with now. Here's hoping we can get it fixed quickly.
Hi John. Just to let you know that DreamHost recognised this as a MySQL problem shared by several of their users, and moved our MySQL to one of their servers that a fix is being tested on. This seems to have resolved the issue - hope it will prove useful for anyone encountering similar time-outs.
Thanks again for your help!