Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Deploying a 2nd time causes drush to hang #5

Open
unityweb opened this Issue · 6 comments

3 participants

@unityweb

What can bw wrong there ?

Error executing action run on resource 'execute[drush_en_module views]'

Mixlib::ShellOut::ShellCommandFailed

Expected process to exit with [0], but received '1'
---- Begin output of /usr/local/drush/drush -y en views ----
STDOUT:
STDERR: Command pm-enable needs a higher bootstrap level to run - you will [error]
need invoke drush from a more functional Drupal environment to run
this command.
The drush command 'en views' could not be executed. [error]
Drush was not able to start (bootstrap) the Drupal database. [error]
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.14
Site URI : http://default
Database driver : mysql
Database hostname : localhost
Database username : drupal
Database name : drupal
Default theme : garland
Administration theme: garland
PHP configuration : /etc/php5/cli/php.ini
Drush version : 5.4
Drush configuration:
Drupal root : /var/www/drupal
Site path : sites/default
Modules path : sites/all/modules
Themes path : sites/all/themes
File directory path: sites/default/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.
---- End output of /usr/local/drush/drush -y en views ----
Ran /usr/local/drush/drush -y en views returned 1

@mdxp
Owner

This indicated that drupal was not installed correctly. Please verify that and see if that is the case.

@dkinzer

This was happening to me too, but then It started working once I added overrides for drupal attributes.

override_attributes(
  "mysql" => {
    "server_root_password" => "iloverandompasswordsbutthiswilldo",
    "server_repl_password" => "iloverandompasswordsbutthiswilldo",
    "server_debian_password" => "iloverandompasswordsbutthiswilldo"
  },
  "drupal" => {
    "db" => {"password" => "drupalpass2"},
    "dir" => "/var/www/html/cdb"
  },
  "hosts" => {
    "localhost_aliases" => ["cdb.dev", "cdb-dev", "localhost"]
  }
)

default_attributes(
  "apache2" => {
    "listen_ports" => ["80", "443"]
  }
)

I think that for some reason the cook-book defaults do not work.

@mdxp
Owner

What attribute was needed to be overwritten? the mysql passwords?

@dkinzer

@mdxp I haven't figured that out yet. I just noticed that you override these in your Vagrantfile's Chef provisioning section so I thought I would try that, and that worked for me.

@mdxp
Owner

I can assume the mysql password is the issue. Let me know what you found out.

@dkinzer

@mdxp sorry I couldn't get back to this earlier.

You're absolutely correct. The problem has to do with node['drupal']['db']['password'].

In the default attributes file , the password is set with set_unless['drupal']['db']['password'] = secure_password

Which means that in the case that someone did not provide an override for the password, there is a conflict the second time one cooks because presumably secure_password does not return the same password it gave the first time.

I can reproduce the issue another way: which is to override the db password before the first time I provision the VM. The next time I run cook without changing the password nothing happens. However, if I modify my config file to change the password for the db, then the build fails.

If I then revert the password in the configuration to the original password, and cook again, the build does not fail.

So the bug is that as it stands, the recipe does not know how to handle a change in the database password.

@dkinzer dkinzer referenced this issue from a commit in jenkinslaw/drupal-cookbook
@dkinzer dkinzer Add and use settings.php template.
When a change is made to the databse password attribute it is not reflected in settings.php.  The result is that the code base can no longer comminicate with its database and problems such as those described in promet/drupal-cookbook#5 arise.

This issue is partly the result of using drush-install to install drupal and not using a template to override the settins.php file.

Unfortunately drush-install does not currently allow a changes to settings.php file via the command line (as far as I'm aware).  Therefore, this issue reimplements the template process for configuring the settins.php file.  Since d7 and d6 have different settins.php formats, a template is provided for each (@todo add d8 template).

This reverts part of commit 4547328.

Conflicts:
	attributes/default.rb
	metadata.rb
	recipes/default.rb
7c2a4e0
@dkinzer dkinzer referenced this issue from a commit in jenkinslaw/drupal-cookbook
@dkinzer dkinzer Add and use settings.php template.
When a change is made to the databse password attribute it is not reflected in settings.php.  The result is that the code base can no longer comminicate with its database and problems such as those described in promet/drupal-cookbook#5 arise.

This issue is partly the result of using drush-install to install drupal and not using a template to override the settins.php file.

Unfortunately drush-install does not currently allow a changes to settings.php file via the command line (as far as I'm aware).  Therefore, this issue reimplements the template process for configuring the settins.php file.  Since d7 and d6 have different settins.php formats, a template is provided for each (@todo add d8 template).

This reverts part of commit 4547328.

--amend:
 (1) Remove trailing comma.
e2cd1f0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.