The Dropbox plugin fails

Subtitle: The Dropbox plugin fails emitting an error: “Zend_Db_Adapter_Mysqli_Exception”.

We recently upgraded to Omeka 2.5.1 from Omeka 2.4.1. The Dropbox plugin has become increasingly unstable following an upgrade several months ago to 2.4.1 and now with the latest upgrade.

  1. Dropbox will not allow any file size greater than about 1 MiB or so. Formerly, it would process images with file sizes of 50 MiB or more.

  2. Attempts at directly uploading (don’t use Dropbox at all) results in a similar error.

When using Dropbox, Omeka crashes, usually after a couple of runs (adding files with Dropbox), emitting the error “Zend_Db_Adapter_Mysqli_Exception: No such file or directory in /var/www/html/omeka-2.5.1/application/libraries/Zend/Db/Adapter/Mysqli.php:340
Stack trace:” (The stack trace consists of about 30 lines of data.)
I believe we have an errant table in the MySQL database.

Along a similar vein, the SimpleVocab plugin which formerly worked, does not work at all. Omeka randomly crashes when SimpleVocab is installed. Removing the plugin as well as removing the entry for the SimpleVocab plugin in the omeka_plugins table in the supporting MySQL data allows Omeka to run.

We are running on a self-hosted Ubuntu 16.04 server installed as an “A0” image in Microsoft Azure.

We ran mysqlcheck across all the database tables. All are reported ‘OK’. This finding suggests that the problem lies in the Omeka installation and not in MySQL.

More troubleshooting reveals the following observations:
Restart the Ubuntu 16.04 server.
phpinfo reports that the mysqli.default_socket resides at /var/run/mysqld/mysqld.sock.
This file location is consistent with that listed in /etc/php/7.0/apache2/php.ini
The command ps -A | grep mysql reports the mysqld daemon running.
Immediately following the Zend_Db crash, the command ps -A | grep mysql reports mysql-systemd-s running. (See below)
Moments later, a ps -A | grep mysql reports that mysqld is again running.
However, at this stage /var/run/mysqld/mysqld.sock does not exist.
Clearly, the crash sequence is doing something to the MySQL server.
We also note, that when mysql-systemd-s is running, it is impossible to start and stop the mysql server with the systemctl start, stop or restart commands.
Whenever mysql-systemd-s is running, the command systemctl status mysql reports that the mysql server is in a crashed state.
Whenever mysqld is running, the command systemctl status mysql reports that msyql is up and operational.
Investigation thus far shows that the only way to restore /var/run/mysqld/mysqld.sock is to restart the Ubuntu 16.04 server. (sudo shutdown -r now in an SSH session, or vm restart --resource-group xxx --name xxx from the local command line).
It is still impossible, under any circumstance to use Dropbox to attach a file with a size of more than 1 MiB or so to an Omeka item.
Anything else we can do?
Thanks for anyone’s help!

This topic was automatically closed 250 days after the last reply. New replies are no longer allowed.