I updated BOA from 1.4s to 2.0.1 this morning and then tried to migrate a site from OpenAtrium 1.0 to 1.1.1, both using the stock distros installed by Octopus (plus a couple of additional modules). After 45 minutes trying to migrate, I deleted the Migrate task in Aegir and attempted to Verify. I let that run for over 90 minutes and the task was still spinning.

I use a Linode with Ubuntu Lucid, and get their emails about exceeding my disk IO threshold of 1000 for 2 hours (it's closer to 4100). This makes me think that Drush is possibly pegging the system?

The site works fine in its current state, and Chive shows the Migrate task partially created a new database. The task step that hangs is:
Running: /data/disk/octopusadmin/tools/drush/drush.php @atrium.parkcirclefilms.org provision-verify --backend 2>&1

barracuda_log.txt shows no errors, but here are the recent entries:

Sun Oct 30 09:10:34 EDT 2011 / Ubuntu.lucid i686 XEN / Aegir BOA-1.4S / Barracuda BOA-1.4S / Nginx 1.0.8 / PHP 5.2.17 / MariaDB dev.parkcirclefilms.org / SpeedWild YES-NO
Mon Jan  2 12:53:23 EST 2012 / Ubuntu.lucid i686 XEN / Aegir BOA-2.0.1 / Barracuda BOA-2.0.1 / Nginx 1.0.11 / PHP 5.2.17 / MariaDB dev.parkcirclefilms.org / SpeedWild YES-NO

octopus_log.txt is similar:

Sun Oct 30 10:11:02 EDT 2011 / Ubuntu.lucid i686 / Aegir BOA-1.4S / Octopus BOA-1.4S
Mon Jan  2 13:02:20 EST 2012 / Ubuntu.lucid i686 / Aegir BOA-2.0.1 / Octopus BOA-2.0.1

Not sure if this is related, but verifying a different site (on a different platform) fails with:
Drush command terminated abnormally due to an unrecoverable error.

This occurs after these steps:

In post verify: Fetching CiviCRM Drush options
CiviCRM: running post verify.

Other sites on other (D7) platforms finish the Verify task properly.

What steps can I take to try to resolve this?

Comments

omega8cc’s picture

Component: Code » Miscellaneous

If you have added "plus a couple of additional modules" then it is no longer a "stock distro", right?

Anyway, always verify both old and new platform (and the site) before attempting migration.

Also, never migrate live site unless you tested it on the cloned copy of the site.

If this still fails, try to move away the /data/disk/USER/.drush/provision_civicrm directory temporarily and then try again.

narayanis’s picture

Both OpenAtrium 1.0 and 1.1.1 platforms do verify successfully; the additional modules I added are filefield, logintoboggan, print, and wysiwyg. It is the Verify task for the site that never completes, and that same Verify task that appears to be causing MySQL table crashes, which I'm guessing is related. I only get the SQL CHECK emails when attempting to Verify the site.

Would provision_civicrm have an effect even though the site that hangs doesn't have that module (thus it isn't being called)? It's a different site that receives that error, which is why I am unsure if the error is related to the hanging task on this site.

omega8cc’s picture

The /data/disk/USER/.drush/provision_civicrm extra module is loaded always, if exists, on every Provision task, not just for CiviCRM enabled sites. Try to move it away to see if this causes/fixes the problem.

narayanis’s picture

I moved provision_civicrm out of the .drush folder and my sites now Verify without hanging or producing errors. However, Clone and Migrate still hang and I still receive SQL check messages after 8-10 minutes of processing, which possibly point to table crashes.

omega8cc’s picture

So, maybe run db repair with bash /var/xdrago/mysql_repair.sh and then watch the tail -f /var/log/syslog | grep mysql during another Clone or Migrate to see when/why it crashes. Maybe you need to raise some limits for MySQL server or maybe it will be enough to move away files directories and symlink them if they are too big, so it hits default limits set either for php-cli or mysql.

narayanis’s picture

Running mysql_repair.sh fixed the problems! Thank you so much!

narayanis’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

updated for clarity