Drupal 7 site Provisioning Broken in some cases?

I think I'm seeing it also on Aegir 1.1 (using Ubuntu 8.04).

I successfully created a D7 platform. I then create a site, which fails. The error message I get is: "The command could not be executed successfully (returned: Segmentation fault , code: 139)." The next line starts off with: "Drush was not able to start (bootstrap) the Drupal database." I try to delete the site using a delete task, which also fails telling me it's "unable to drop the database." All this is done through the Aegir front end.

Looking under the hood a bit, there is a .drush alias, there is a platform/drupal/sites/site_name/settings.php but it's otherwise empty, and the clients/admin alias, vhost files and database aren't there.

This is my first D7 site (using Drupal 7.7). I can create a D6 site just fine.

I'm still experiencing this issue.

I rebooted the server thinking the server troll prevented my php-cli change from taking. That didn't work. I then increased /etc/php5/cli/php.ini to 256MB and /etc/php5/apache2/php.ini to 192MB. It choked again at the point I mentioned in #1. I then created a completely new site on a new platform (this time using D7.0). Again choked. I increased /etc/php5/apache2/php.ini to 256MB so it matched the php-cli memory limit. Choke. When I look in the task transcript, the highest "peak memory usage" was 17.03 MB.

My D6 platform installs the site without incident.

Can we get a traceback with --debug?

Same issue.

How do I do what you are asking?

You can copy-paste the log from the "view" button in the task, or run the task with:

drush @hostmaster hosting-task <nid> --debug

where is the node id of the task.

Thank you. I have sent the logs to you in a PM.

My thanks also. I sent my logs to you by PM.

Were the logs received?

Anarcat is on Holiday until the start of Oct, so you're unlikely to get a response until then, sorry!

Why you guys sent me this in private is beyond me. This is an open source project, you are going to have much better luck in publishing them publicly than relying on my personal expertise, as this long delay has proven. :)

I'll see if I have time to look at this this week.

I felt there was client info in the transcript I didn't want to publicize.

You seem to be having almost exactly the same problem. The fact that PHP is segfaulting is a really good sign that something is very wrong, even outside of aegir.

I have seen such problems with PHP 5.2.17-0.dotdeb.0 on Debian. Upgrading to PHP 5.3 has fixed the problem for us. What version of PHP are you running?

To confirm it is the same problem, try running the install under "strace", you should see something like this:

19692 open("/srv/aegir/platforms/drupal-7.0-3.3-production/modules/system/system.mail.inc", O_RDONLY) = 5
19692 fstat(5, {st_mode=S_IFREG|0644, st_size=3847, ...}) = 0
19692 read(5, "<?php\n// $Id: system.mail.inc,v 1"..., 8192) = 3847
19692 read(5, ""..., 8192)              = 0
19692 read(5, ""..., 8192)              = 0
19692 close(5)                          = 0
19692 mmap(NULL, 35917824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8462c1e000
19692 --- SIGSEGV (Segmentation fault) @ 0 (0) ---

... basically, PHP 5.2.17 doesn't like system.mail.inc, in particular that function:

  public function format(array $message) {
    // Join the body array into one string.
    $message['body'] = implode("\n\n", $message['body']);
    // Convert any HTML to plain-text.
    $message['body'] = drupal_html_to_text($message['body']);
    // Wrap the mail body for sending.
    $message['body'] = drupal_wrap_mail($message['body']);
    return $message;
  }

... of which you can try to comment out the three assignations, which got rid of the segfault for us (but broke mail sending, obviously, and may even be a security vulnerability).

So I suspect the problem is outside the scope of Aegir. Try to upgrade PHP.

See also #864940: WSOD - No errors logged..

Thanks for looking at this. I was sidetracked for a while on a different issue that has some relevance here for me: I found I can't upgrade php to 5.3 at the moment (currently using 5.2.13-0.dotdeb.0). I forget exactly why now, but it had something to do with depreciated functions in 5.3 that caused some of my D6 modules to throw errors.

I may not be stuck, though. Anarcat's post got me thinking. I created a barebones test site in D6.22 and migrated it to a D7.7 platform. It mostly worked. I got an error on the upgraded site (Undefined index: distribution_name in drupal_install_profile_distribution_name()). These discussions led me to a workaround:
http://drupal.org/node/1170362
http://drupal.org/node/1170360

I can't say it's resolved me, but if it works it works.

This seems pretty consistent with a number of people receiving the issue. I don't see how this can't be solved in Aegir. PHP 5.2 seems to have the issue, I too encountered it on D7 sites. It should be reproduced on most debian based php 5.2 servers.

Here are the errors I received, even changed cli php.ini and apache php.ini to 512M then restarted apache:

The command could not be executed successfully (returned: sh: line 1: 6567 Segmentation fault /usr/share/drush/drush.php --client_email='admin@myserver.com' @mysite.com provision-install-backend --backend 2>&1 , code: 139)

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 : mysite.com Default theme : garland Administration theme: garland PHP configuration : /etc/php5/cli/php.ini Drush version : 4.5 Drush configuration: /var/aegir/platforms/drupal-7.10-community/sites/mysite.com/drushrc.php /var/aegir/platforms/drupal-7.10-community/drushrc.php Drush alias files : /var/aegir/.drush/mysite.com.alias.drushrc.php /var/aegir/.drush/server_master.alias.drushrc.php /var/aegir/.drush/platform_CommunityDrupal710.alias.drushrc.php /var/aegir/.drush/othersite1.com.alias.drushrc.php /var/aegir/.drush/othersite2.com.alias.drushrc.php /var/aegir/.drush/platform_Drupal622Plain.alias.drushrc.php /var/aegir/.drush/platform_Drupal622Typical.alias.drushrc.php /var/aegir/.drush/myserver.com.alias.drushrc.php /var/aegir/.drush/platform_hostmaster.alias.drushrc.php /var/aegir/.drush/hostmaster.alias.drushrc.php /var/aegir/.drush/othersite3.alias.drushrc.php /var/aegir/.drush/othersite4.com.alias.drushrc.php Drupal root : /var/aegir/platforms/drupal-7.10-community Site path : sites/mysite.com Modules path : sites/mysite.com/modules Themes path : sites/mysite.com/themes File directory path: sites/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. 

I also tried verifying my platform again and saw this in the log:

Undefined index: old_short_name hosting_package.module:394
Undefined index: old_short_name hosting_package.module:394
Undefined index: old_short_name hosting_package.module:394
Undefined index: old_short_name hosting_package.module:394
Undefined index: old_short_name hosting_package.module:394
Undefined index: old_short_name hosting_package.module:394
Undefined index: old_short_name hosting_package.module:394
Undefined index: old_short_name hosting_package.module:394
Undefined index: old_short_name hosting_package.module:394
Undefined index: old_short_name hosting_package.module:394
Command dispatch complete
Peak memory usage was 26.4 MB

don't know if that might be an issue or not.

Having the same problem, but with a newer php version (on Ubuntu server):

PHP 5.3.6-13ubuntu3.6 with Suhosin-Patch (cli) (built: Feb 11 2012 02:17:16) 
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

Same or similar issue for me:

PHP 5.2.17 with Suhosin-Patch 0.9.7 (cli) (built: Mar 14 2012 18:14:33) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies

Memory limit is 512M and it never gets anywhere near to using all of that.

Can people still reproduce this issue?

I was definitely able to on PHP 5.2, I upgraded my server to 5.3 and now everything seems fine.

adding php cli version

The 1.x branch is deprecated. If this remains an issue in 3.x, feel free to re-open.