0

I have a bunch of sites on my local machine and have been using Drush (v5.4) happily for a long time to administer them.

All of a sudden, with no changes made to one such site, Drush reports these errors:

Command pm-disable needs a higher bootstrap level to run - you will need invoke drush from a more functional Drupal environment to run this command.

The drush command 'dis addthis' could not be executed.

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.

Needless to say the site in question is running fine on the local machine with no errors (and is completely installed). Drush works fine for every other site on the machine.

What can cause Drush to suddenly misbehave like this for one particular site?

| improve this question | |
  • What is the output of drush status? – Sam152 Jul 9 '12 at 13:07
  • It says there's a permissions problem with the site's settings.php...I've checked, there isn't – Clive♦ Jul 9 '12 at 13:10
  • Not to worry, running it as root fixes the error. Will just have to live with it for this site I guess – Clive♦ Jul 9 '12 at 13:11
  • Have you ensured that your sites directory is owned by the correct user and has the correct permissions? – Sam152 Jul 9 '12 at 13:49
  • @Sam152: Yep, permissions are the same as every other site on my machine and Drush works fine on all of those – Clive♦ Jul 9 '12 at 13:50
1

Drush, being run from the command line might have different permissions than the web server. Essentially your site can work correctly but some files might be in accessible from drush. If you are running into errors you might want to ensure that the group permissions of your entire Drupal site are set correctly by running:

chown -R owner:group sites_directory

If you run into permission denied errors as the result of running chown, run it as sudo or contact your system administrator.

| improve this answer | |
  • Just be careful when you do this. Doing it on sites/ can cause sites/default/files (or whatever your files dir is) to become unwritable by the webserver. I typically follow the above command with shown -R apache.apache sites/default/files/ – mpdonadio♦ Jul 10 '12 at 1:05
  • I guess it depends on the server setup. My understanding is that the webserver should be running as the user that is the account is setup under, in a cPanel environment anyway. – Sam152 Jul 10 '12 at 2:05
  • Having Apache be able to write to the site code is a bit of a security risk. Ideally, it should be limited to write access to the private and public file paths. – mpdonadio♦ Jul 10 '12 at 10:34
1

I cannot answer why this happens, but I have a site that periodically does this with drush pm-enable. I think this site has trouble doing the nightly module update check, and something bad gets cached. A drush cc all always fixes it.

| improve this answer | |
  • Thanks, unfortunately drush cc all also fails with the same error message. Weird – Clive♦ Jul 9 '12 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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