This one is a bitch:

Changed permissions of drushrc.php to 0600 [16.78 sec, 7.6 MB]                                                [message]
Running:  /usr/bin/php /srv/aegir/drush/drush.php --php=/usr/bin/php                                          [command]
--uri='http://test.example.com' --root='/var/aegir/stage-1.0-drupal-6.16' updatedb --backend
The external command could not be executed due to an application error. [226.62 sec, 7.6 MB]                [error]
Undefined index:  driver environment.inc:926 [226.62 sec, 7.6 MB]                                              [notice]
Undefined index:  driver environment.inc:926 [226.62 sec, 7.6 MB]                                              [notice]
PDO support available, but the  driver has not been installed. Assuming success. [226.62 sec, 7.6 MB]       [bootstrap]
An error occurred at function : drush_provision_drupal_post_provision_deploy [226.62 sec, 7.6 MB]           [error]
Removed apache virtual host configuration [226.63 sec, 7.61 MB]                                               [message]

Which application error?! There is no output whatsoever from drush, and no information I can find in any logs. Digging further, I see that updatedb *seems* to work at first glance:

$ /usr/bin/php /srv/aegir/drush/drush.php --php=/usr/bin/php --uri='http://test.example.com' --root='/var/aegir/stage-1.0-drupal-6.16' updatedb  --debug ; echo $?
Drush bootstrap phase : _drush_bootstrap_drupal_root() [0.09 sec, 5.08 MB]                                  [bootstrap]
Loading drushrc "/srv/aegir/stage-1.0-drupal-6.16/drushrc.php" into "drupal" scope. [0.09 sec, 5.09 MB]     [bootstrap]
Initialized Drupal 6.16 root directory at /var/aegir/stage-1.0-drupal-6.16 [0.12 sec, 7.13 MB]                 [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [0.13 sec, 7.24 MB]                                  [bootstrap]
Initialized Drupal site staging.sciencepresse.info at sites/test.example.com [0.23 sec, 7.46 MB]     [notice]
Loading drushrc "/srv/aegir/stage-1.0-drupal-6.16/sites/test.example.com/drushrc.php" into "site" [bootstrap]
scope. [0.23 sec, 7.47 MB]
Found command: updatedb (commandfile=core) [0.25 sec, 7.62 MB]                                              [bootstrap]
Initializing drush commandfile: drush_make [0.25 sec, 7.62 MB]                                              [bootstrap]
Initializing drush commandfile: drush_make_d_o [0.25 sec, 7.62 MB]                                          [bootstrap]
Initializing drush commandfile: provision [0.25 sec, 7.62 MB]                                               [bootstrap]
Initializing drush commandfile: provision_apache [0.25 sec, 7.62 MB]                                        [bootstrap]
Initializing drush commandfile: provision_drupal [0.25 sec, 7.62 MB]                                        [bootstrap]
Initializing drush commandfile: provision_mysql [0.25 sec, 7.62 MB]                                         [bootstrap]
Including version specific file : /srv/aegir/drush/commands/core/drupal/update_6.inc [0.25 sec, 7.64 MB]       [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_configuration() [0.26 sec, 7.79 MB]                         [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_database() [0.37 sec, 12.96 MB]                             [bootstrap]
Successfully connected to the Drupal database. [0.37 sec, 12.96 MB]                                         [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [0.37 sec, 13.18 MB]                                 [bootstrap]
255

So there's an error in the bootstrap somewhere that does make PHP return error code 255 (APPLICATION ERROR according to drush).

Drush eval gives a way more informative result:

$ drush eval "print 1;"

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 30720 bytes) in /srv/aegir/stage-1.0-drupal-6.16/sites/all/modules/patched/twitter/twitter_signin/twitter_signin.module on line 167

Ah. So that's a memory exhaustion error!!! Aaaaaah, now I know. But there was no error message of any kind in updatedb...

Comments

Anonymous’s picture

Anonymous (not verified) commented

Yeah I hate this one.. I actually kind of got used to it/living with it. There was another ticket in the queue just now where I was able to debug the user's issue to their memory_limit based on the fact that the Drush output *was* so unhelpful :)

I wonder if this is actually a Drush thing rather than Provision? i.e is Drush itself not equipped to capture an OOM and throw the exception? Maybe it's just a case of PHP sucking?

anarcat’s picture

anarcat commented

Yes, I think this could escalate pretty high up. I wasn't sure at first that the problem was in drush, but the more I think about it, the more i think it's where we should address it. It's also probably a case of PHP sucking, so it's possible that drush can't do anything about it.

One thing though: we could have a workaround. We're dealing with the tasks and invokes... we could handle it more gracefully while we wait for drush to fix its stuff.

Besides, that issue is not well conceived enough yet to be moved to drush's too busy queue. I think we could keep it here to track our end of it and then open a new in Drush's queue that would be more ... descriptive and proactive on the potential solutions or path forward.

adrian’s picture

adrian commented
Status: Active » Fixed

I've isolated this into it's own hidden command, namely 'provision-install-backend', that only does the drush_include_engine bit.

this means that if it dies we can recover gratefully.
From my testing, this has also solved out 'SITE_INSTALLED' problem, as we now correctly roll back and remove the detritus.

Status: Fixed » Closed (fixed)

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