Following the instructions at: http://community.aegirproject.org/installing/manual for doing a manual 2.x install on Ubuntu 12.04 on Amazon EC2, I get the following error:

This command will replace your crontab for this user. continue? (y/n): y
/usr/share/php/drush/drush.php '@hostmaster' hosting-dispatch 
sh: 1: /usr/share/php/drush/drush.php: Permission denied
Dispatch command could not be run. Returned:                                               [error]

The command did not complete successfully, please fix the issues and re-run this script    [error]

This is using the Drush install from Pear, under the 'Note for 2.x users' bit in the documentation. For some reason Provision expects /usr/share/php/drush/drush.php to be executable, but with Drush installed from Pear it's not.

Workaround: running chmod +x /usr/share/php/drush/drush.php got rid of the error and installation completed successfully.

Strictly speaking, this occurred on 2.0-rc2. However, checking the commit messages since that release there doesn't appear to be any change which would fix this.

CommentFileSizeAuthor
#2 hosting-2050881-2.patch456 bytesergonlogic
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ergonlogic’s picture

This should probably be calling the 'drush.sh' script rather than 'drush.php' directly.

ergonlogic’s picture

Project: Provision » Hosting
Component: Drush integration » Code
Status: Active » Needs review
FileSize
456 bytes

FYI, it looks like there's a long backstory to this: #586466: Drush.php is no longer directly executable (can interfere with backend invoke). I've filed a new bug report upstream: #2059225: drush.php is not executable with PEAR install

As for how we can fix this ourselves, we use a constant defined by Drush, DRUSH_COMMAND, that is supposed to provide us with an executable command that can be used to call Drush again. Unfortunately, it appears to always return 'drush.php' even when calling Drush through its shell script, and regardless of whether drush.php is executable. I think our best bet is to call '/usr/bin/env php DRUSH_COMMAND' instead.

ergonlogic’s picture

Status: Needs review » Fixed

I pushed this fix, in preparation for 2.0-rc3, in commit ee71bab.

Liam McDermott’s picture

Great, thanks ergonlogic!

anarcat’s picture

Status: Fixed » Needs work

i don't think env php solves the general case, we should use internal drush procedures for calling itself, as discussed on irc - drush_build_command()?

  • Commit ee71bab on 6.x-2.x, 7.x-3.x, dev-ssl-ip-allocation-refactor, dev-sni, dev-helmo-3.x by ergonlogic:
    Issue #2050881: Call drush.php via php, since it isn't executable when...

  • Commit ee71bab on 6.x-2.x, 7.x-3.x, dev-ssl-ip-allocation-refactor, dev-sni, dev-helmo-3.x by ergonlogic:
    Issue #2050881: Call drush.php via php, since it isn't executable when...

  • ergonlogic committed ee71bab on dev-helmo-3.x
    Issue #2050881: Call drush.php via php, since it isn't executable when...

  • ergonlogic committed ee71bab on 7.x-3.x-1995506
    Issue #2050881: Call drush.php via php, since it isn't executable when...

  • ergonlogic committed ee71bab on dev-2223033
    Issue #2050881: Call drush.php via php, since it isn't executable when...

  • ergonlogic committed ee71bab on dev-2359571
    Issue #2050881: Call drush.php via php, since it isn't executable when...

  • ergonlogic committed ee71bab on 7.x-4.x
    Issue #2050881: Call drush.php via php, since it isn't executable when...
ergonlogic’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)

The 6.x-2.x branch will go EOL along with Drupal this week. So I'm closing this issue. If it remains a confirmed issue in 7.x-3.x, feel free to re-open, or better yet, create a new issue referencing this one.