I'm unable to get some functions of my Octopus instance to run correctly. Verify and backup work with no problem. Clone and migrate fail to run successfully.

In the log message, right after this (names sanitized):
Running: /data/disk/myclient/tools/drush/drush.php @client.site.com updatedb --backend 2>&1

I see this:
The external command could not be executed due to an application error.

Later in the log message, I find after this:
Drush bootstrap phase : _drush_bootstrap_drupal_full()

This:
Drush command terminated abnormally due to an unrecoverable error. Error: require_once(): Failed opening required '/data/disk/etclient/distro/001/drupal-7.10-stage/sites/client-dev.mysite.com/modules/context/plugins/context_condition_node.inc' (include_path='.:/usr/local/lib/php') in /data/all/001/drupal-7.10-stage/includes/bootstrap.inc, line 2982

And this:
Drush was not able to start (bootstrap) the Drupal database. Hint: This error often occurs when Drush is trying to bootstrap a site that has not been installed or does not have a configured database. Drush was attempting to connect to : Drupal version : 7.10 Site URI : myclient.mysite.com Default theme : garland Administration theme: garland PHP configuration : /usr/local/lib/php.ini Drush version : 4.5 Drush configuration: /data/disk/etclient/distro/001/drupal-7.10-stage/sites/myclient.mysite.com/drushrc.php /data/disk/etclient/distro/001/drupal-7.10-stage/drushrc.php Drush alias files : /data/disk/etclient/.drush/myclient.mysite.com.alias.drushrc.php /data/disk/etclient/.drush/server_master.alias.drushrc.php /data/disk/etclient/.drush/platform_Drupal710S001.alias.drushrc.php /data/disk/etclient/.drush/etclient.mysite.com.alias.drushrc.php /data/disk/etclient/.drush/openpublic.mysite.com.alias.drushrc.php /data/disk/etclient/.drush/platform_OpenPublicbeta3710P001.alias.drushrc.php /data/disk/etclient/.drush/platform_hostmaster.alias.drushrc.php /data/disk/etclient/.drush/platform_002.alias.drushrc.php /data/disk/etclient/.drush/client-dev.mysite.com.alias.drushrc.php /data/disk/etclient/.drush/hostmaster.alias.drushrc.php /data/disk/etclient/.drush/platform_Drupal710P001.alias.drushrc.php /data/disk/etclient/.drush/platform_Drupal710D001.alias.drushrc.php Drupal root : /data/disk/etclient/distro/001/drupal-7.10-stage Site path : sites/myclient.mysite.com Modules path : sites/myclient.mysite.com/modules Themes path : sites/myclient.mysite.com/themes File directory path: sites/myclient.mysite.com/files %paths : Array You can select another site with a working database setup by specifying the URI to use with the --uri parameter on the command line or $options['uri'] in your drushrc.php file.

The messages above are from a migrate attempt, but I've seen similar messages from attempts to clone.

From my octopus_log.txt:

Sat Jan  7 20:31:20 UTC 2012 / Debian.squeeze x86_64 / Aegir BOA-1.4S / Octopus BOA-1.4S
Sun Jan  8 20:50:25 UTC 2012 / Debian.squeeze x86_64 / Aegir BOA-1.4S / Octopus BOA-1.4S

From my barracuda_log.txt

Tue Dec 20 21:29:51 UTC 2011 / Debian.squeeze x86_64 XEN / Aegir BOA-1.4S / Barracuda BOA-1.4S / Nginx 1.0.8 / PHP 5.2.17 / MariaDB mysite.com / SpeedWild YES-NO
Sun Jan  1 04:04:51 UTC 2012 / Debian.squeeze x86_64 XEN / Aegir BOA-2.0.1 / Barracuda BOA-2.0.1 / Nginx 1.0.11 / PHP 5.2.17 / MariaDB mysite.com / SpeedWild YES-NO
Fri Jan  6 03:32:00 UTC 2012 / Debian.squeeze x86_64 XEN / Aegir BOA-2.0.1 / Barracuda BOA-2.0.1 / Nginx 1.0.11 / PHP 5.2.17 / MariaDB mysite.com / SpeedWild YES-NO

I tried to search for references to this problem and the closest I could find were mentions of memory_limit in php.ini for the CLI. I only found two php.ini files: /opt/etc/php.ini and /usr/local/lib/php.ini. Neither one had memory_limit set low. Perhaps I was going down the wrong path, but I couldn't find any indication of a problem there.

Comments

jimsmith’s picture

jimsmith commented
Component: User interface » Miscellaneous
omega8cc’s picture

omega8cc commented

This is nothing really BOA specific and the errors are pretty self-explaining.

This is really a bad idea to use site specific sites/domain/modules space for modules, because any modules located there are never checked
for compatibility on clone/migrate tasks by Aegir, and they are moved as-is, with all site specific files, so it may cause all kinds of WTF issues, including mysteriously failed tasks in Aegir and WSOD, because some files required as includes are not yet or not already in the expected path.

The solution is to always use platform specific sites/all/modules space, which is a part of Aegir best practices.

You can still use site specific space for themes and some modules you have to separate from other sites on the same platform, but be prepared for such issues if any of them relies on includes located in this space.

jimsmith’s picture

jimsmith commented

Thanks for the clarification. I was mistakenly under the impression that the site-specific modules directory was the best location for modules in an Aegir/Octopus installation. Perhaps I just assumed this location would make the modules more 'portable.'

clarkburbidge’s picture

clarkburbidge commented

In the case where a majority of modules are in the sites/all/modules space, what does one do with the modules in the sites/domain/modules space during clone/migrate?

I've tried to copy all the modules/themes/libraries to the "all" space but end up with bootstrap errors. What is the migrate method?

omega8cc’s picture

omega8cc commented

You need to remove all modules from sites/domain/modules if you have uploaded them also to sites/all/modules. Normally it is enough to clear all caches then, but sometimes you have to edit paths in the system table, to avoid WSOD because of missing includes expected by some modules.

omega8cc’s picture

omega8cc commented
Status: Active » Closed (works as designed)