I'm trying to get a site from one Aegir installation to a new one based on http://community.aegirproject.org/node/117
Similar to http://drupal.org/node/739830 the provision-deploy command gives an "The external command could not be executed due to an application error."
Using the --debug parameter I found out the call was to 'updatedb', but that didn't help me mush
It turned out that the database server configuration in Aegir was incorrect, probably my mistake, but finding that out was a painful process.
Xdebug eventually showed me that the db service used from db/deploy.provision.inc was provisionService_null, which explains why it silently failed.
I'm not sure what the best place is for handling this error but it sure would have saved me a lot of time had I seen this earlier.
Wouldn't it be possible to check in drush_db_provision_deploy_validate() if the db service object is usable? Giving a fatal error other wise.
Along the way I was distracted by warnings like:
Undefined index: profiles deploy.provision.inc:84 [1.52 sec, 5.88 MB] [notice]
array_keys() expects parameter 1 to be array, null given deploy.provision.inc:84 [1.52 sec, 5.88 MB] [warning]
Which I've tried to patch using provision-check_package_list.patch
And an "Undefined index: driver environment.inc:939" , which seems to be fixed in the latest drush head.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | provision-check_package_list_0.patch | 640 bytes | helmo |
| provision-check_package_list.patch | 630 bytes | helmo |
Comments
Comment #1
anarcat commentedTry drush_set_error() to flag an error in drush.
Otherwise, it looks like you forgot to set the profile in the provision-save command.... I'll be reviewing those instructions shortly personnally...
Comment #2
helmo commentedOK, I've adapted the patch to use drush_set_error.
Is it also required to add something to provision_drupal_drush_help() about this?
After all the debug steps I've gone through I'm uncertain what actually caused this.
The good thing is that I managed to import the sites I wanted.
Comment #3
anarcat commentedFixed and merged in master. I did not "return" to follow style used elsewhere in this function...
Comment #4
anarcat commentedActually, thinking back - i think this will create problems for sites that don't have *any* site-specific modules, which is fairly common...
So maybe the original warning was right, but even then - it should not return. We are really hiding another issue that needs to be fixed otherwise here.
What's the bottomline issue here? Could you clarify the issue in the title please?
Comment #5
helmo commentedThe bottom line was that the real error was obfuscated making it harder to debug.
I've split the undefined index $site_packages['profiles'] to #1111572: Migrate doesn't check packages in the backend so that this issue can address the root cause.
Summery:
The db service used from db/deploy.provision.inc was provisionService_null, which explains why it silently failed.
Comment #6
helmo commentedLooking back, this probably is fixed with #1102650: Check db connection before can_create_database()