1

Based on Drush on windows - Command pm-enable needs a higher bootstrap level to run, i have the following question.

I have the same problem found here https://drupal.org/comment/8533097 except I am using Postgresql and this solution did not work for me.

My Drupal installation is at: C:\SiteData\WebDev\gitproject (aka DrupalRoot). I successfully ran drush status in "[DrupalRoot]\sites\site1.example.com, but when I try to enable a module using drush en ccl and I get the following.

Command pm-enable needs a higher bootstrap level to run - you will need to invoke drush from a more functional Drupal environment to run this command. The drush command 'en ccl' could not be executed.
Drush was not able to start (bootstrap) the Drupal database.

Hint: This may occur when Drush is trying to:

  • bootstrap a site that has not been installed or does not have a configured database. In this case you can select another site with a working database setup by specifying the URI to use with the --uri parameter on the command line. See drush topic docs-aliases for details.

  • connect the database through a socket. The socket file may be wrong or the php-cli may have no access to it in a jailed shell. See http://drupal.org/node/1428638 for details

Drush was attempting to connect to:

Drupal version : 7.26
Site URI : http://site1.example.com
Database driver : pgsql
Database username : user
Database name : site1dev
Default theme : garland
Administration theme : garland
PHP executable : php
PHP configuration : "C:\Program Files (x86)\Drush\Php\php.ini"
PHP OS : WINNT
Drush version : 6.0
Drush configuration :
Drush alias files :
Drupal root : c:/SiteData/WebDev/gitproject
Site path : sites/site1.example.com
File directory path : sites/site1.example.com/files

My settings.php file looks like this.

$databases = array (
  'default' => 
  array (
    'default' => 
    array (
      'database' => 'site1dev',
      'username' => 'user',
      'password' => 'secretpw',
      'host' => '127.0.0.1',
      'port' => '',
      'driver' => 'pgsql',
      'prefix' => 'dev_',
    ),
  ),
);


if (php_sapi_name() == 'cli') {
  $db_url = 'pgsql://user:[email protected]/site1dev';
 }
 else {
   $db_url = 'pgsql://user:secretpw@localhost/site1dev';
 }

I have used both the "Drush Command Prompt" and "MINGW32" git command line tool and both work for "drush status" or "drush dl " but not for "drush en "

One last comment. looking at the settings.php file permissions in MINGW32 they show the unix permissions of -rw-r--r--.. Tried changing this in using chmod but doesn't work on a windows file (not even sure that makes a difference).

6
  • make an site alias for Drush, eg: for site example.com make an alias called Drush aliases and put it inside .drush folder, after that drush cc drush and you can invoke the particular site as drush @example.com cc all # just example for clear cache all
    – user12947
    Mar 2, 2014 at 18:33
  • Thanks jhilke-Dai but that did not solve the problem. I was able to add the alias to the site and run drush '@'site1.example.com cc all then run drush '@'site1.example.com status and all worked fine from any command line in Git Bash but when I tried both drush '@'site1.example.com and drush pm-update (from sites room directory) I still get the same error.. It even correctly shows the drush alias path now - c:/Users/ME/.drush/aliases.drushrc.php
    – Cmweb
    Mar 4, 2014 at 0:54
  • One more thing I need to add.. I noticed that the Drush Alias Path looks wrong it is Drush alias files : C:\Users\ME/.drush/aliases.drushrc.php -- see how they go from forward to backslashes ...something wrong here no?
    – Cmweb
    Mar 4, 2014 at 2:11
  • I have no idea about the forward or backward slash, but when you have aliases you don't need to be in Drupal project root to run, you can run the drush @sitename command from anywhere in the terminal, that was the reason the aliases were made.
    – user12947
    Mar 4, 2014 at 7:38
  • did you try drush @site dis ccl drush @site pmu ccl and then enable it again?
    – user12947
    Mar 4, 2014 at 7:39

3 Answers 3

2

I'm not on Windows or using postgres today, but I can suggest how to debug:

What you've got right now is that your cli environment seems to be failing to connect to the database correctly. Checking your database-level access from drush, using verbose (-v) debug (-d) feedback may provide clues.

For instance, given your current failure, I would run

  drush -v -d sql-cli
  • that will, among other things, show you the exact database connection command being attempted that is failing.

You can then copy that yourself, run it again, and see what variations of that command will and will not work. One of the more common issues seems to already be covered (the difference between 'localhost' and '127.0.0.1' depending on installation and version issues. There may be other issues such as 'cannot locate postgres.exe in the current $PATH' or whatever.

This is not an answer to the question, but a suggestion on how to get clueful when a (any) drush command just doesn't work. You can also use the -vd flags on your 'en' command, though I don't know how conclusive the feedback you get there will be.

4
  • Thanks @dman . I ran the above command in my Drupal site folder and was able to connect to the Postgresql database (after a prompt to enter my db user pw) with no problems or errors reported. I still can rush drush status but drush pm-update gives the same error as listed above... :(
    – Cmweb
    Sep 6, 2014 at 17:22
  • 2
    "after a prompt to enter my db user pw" - well that's wrong. If all was well, you would NOT be getting a password prompt, as the system should already know it per settings.php . If you, on the cli, need to put in the password, then the other drush automated processes also need that information. As they do not have it, they will fail. If your settings.php is as shown, with a password really there, then I dunno. I would seriously check that again. And watch out for dangerous characters like #, $ or ; in your configs and db_url Try running drush site-alias --with-db --show-passwords @self
    – dman
    Sep 8, 2014 at 2:20
  • I fixed the drush -v -d sql-cli command password prompt issue.. but now i get the following: Calling proc_open(psql --dbname=mydbname --host=127.0.0.1 --port=5432 --usernam e=myusername); 'psql' is not recognized as an internal or external command, operable program or batch file. Returned from hook drush_sql_cli [16.05 sec, 8.1 MB] [debug] and I can't figure out how to fix this?
    – Cmweb
    Dec 17, 2014 at 0:13
  • When I run the drush site-alias --with-db --show-passwords @self from within my site1.example.com site I get the following:$aliases["self"] = array ( 'root' => 'c:/wamp/www/mydproject', 'uri' => 'site1.example.com', '#name' => 'self', 'databases' => array ( 'default' => array ( 'default' => array ( 'database' => 'mydbname', 'username' => 'myusername', 'password' => 'mypw', 'host' => '127.0.0.1', 'port' => '', 'driver' => 'pgsql', 'prefix' => 'dev_', ), ), ), );
    – Cmweb
    Dec 27, 2014 at 7:30
0

Navigate to http://site1.example.com using cd /sites/site1.example.com and run your drush commands. I had similar problems in the past. The settings.php file in /sites/default/ was not being used and the database entries inside that file were wrong. Everything worked as desired when ran the drush commands within the site folder containing the settings.php file with the correct database credentials.

1
  • The site folder with the settings.php is exactly where i have been running the drush pm-update and drush en {modulename} commands ..save error message always comes up :(
    – Cmweb
    Dec 27, 2014 at 7:35
-1

Add mysql to global path. Worked for me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.