Has anybody ever seen the error message above? Drupal and google searches have not helped.
I have Drupal and Drush installed in different directories in the home directory (the same directory that contains public_html) on a shared support server (Midphase) and everything worked fine until recently when I upgraded to drush-6.x-3.3 from drush-All-versions-3.0-rc4. The reason I upgraded is because I could not get the installed version to work.
[~/drupal/sites]# drush dl backup_migrate
exec() has been disabled for security reasons environment.inc:482 [warning]
SQLSTATE[HY000] [2002] Can't connect to local MySQL server through [warning]
socket '/var/lib/mysql/mysql.sock' (2)
exec() has been disabled for security reasons drush.inc:737 [warning]
exec() has been disabled for security reasons drush.inc:737 [warning]
Unable to download backup_migrate-6.x-2.2.tar.gz to [error]
/home/a4skweb7/drupal/sites/all/modules/ from
http://ftp.drupal.org/files/projects/backup_migrate-6.x-2.2.tar.gz
An error occurred at function : drush_pm_download [error]
[~/drupal/sites]# drush status
exec() has been disabled for security reasons environment.inc:482 [warning]
SQLSTATE[HY000] [2002] Can't connect to local MySQL server through [warning]
socket '/var/lib/mysql/mysql.sock' (2)
Drupal version : 6.16
Site URI : http://test.a4skyhawk.org/
Database driver : mysqli
Database hostname : localhost
Database username : XXXXXXXXXX
Database name : YYYYYYYYYYYY
Default theme : garland
Administration theme : garland
PHP configuration : /usr/local/lib/php.ini
Drush version : 3.3
Drush configuration :
Drupal root : /home/BBBBBB/drupal
Site path : sites/a4skyhawk.org
Just trying to figure out whether the server changed their permissions or whether I screwed something up. I have a ticket in with the company, but if anybody has a solution, I would appreciate it.
Comments
Comment #1
geneatwell commentedThis page (http://drupal.org/node/736824) did not help.
Comment #2
greg.1.anderson commentedThe page you quote is the answer to your problem. If this seems not to be working, call php with the --php-ini commandline arg to specify the php.ini file of your choice. Make sure the php.ini file is configured as described in #736824: Drush persistently failing to run!. See the drush README.txt on how to set up a shell alias to call drush with a custom php or php args.
If this still is not doing the trick, it could be that your ISP patched php to prohibit exec for security purposes. If this is the case, then you simply cannot use drush with this isp. Sorry.
Comment #3
geneatwell commentedThanks, Greg.
I have been working with tech support at the provider for the past two days and they have been extremely responsive. Specifically, they have been adjusting the php.ini file, editing the .htaccess file to make the php.ini recursive and I've even moved the drush directory into the public_html folder with no luck on any level. The php.ini file is in the public_html directory. Should it be elsewhere? Is it being overridden by something else?
I have been able to get the dl switch to download modules into the module directory properly, but no other switches work. The commands start and then fail because the exec() problem does not allow it to access what is needed. The install does not seem to be the problem.
Since they are trying to fix this, are there any other ideas you can think of that will allow Drush to work?
Comment #4
greg.1.anderson commentedSee the related issue #918468: drush.ini or php.ini? [Drush should use php.ini files in drush conf folders + some fixes for drush paths that contain spaces]. It is a bit difficult to configure drush to use its own php.ini file; this patch would make it much easier to do so. Download drush-HEAD and apply this patch, then put the php.ini file that you want to use in $HOME/.drush.
Regarding your questions in #3, note that drush is not and should not be called by the web server, so drush should not be located in public_html. Neither do you want your php.ini file in public_html; tell your ISP to put php.ini back where it was, and keep it configured to prohibit exec. Configure drush to use its own php.ini file that allows exec.
Instead of the above patch (or to use drush-3.x), you could do this (from the README file):
alias drush /path/to/php --php-ini /path/to/php.ini /path/to/drush.php --php="/path/to/php --php-ini /path/to/php.ini"
See, that's a little complicated, isn't it?
Comment #5
moshe weitzman commentedThats an impressive alias
Comment #7
PI_Ron commentedHi,
Ive installed drush in /usr/local/lib/drush
Copied php.ini to /etc/.drush/php.ini
Edited and removed all the disabled_functions from it
Do:
$ drush status
and get:
So, it seems to be using my edited php.ini file, however when i cd to a sites root directory, and run:
drush up status
I get:
It still gives me warnings saying exec() is disabled for...
ahhhhh! Please advise as its done my head in for 3 hours.,,
Comment #8
greg.1.anderson commentedYour report makes no sense to me, because the feature you are using (custom drush php.ini in /etc/drush) is in drush-HEAD, not 3.3. Did you apply a patch from HEAD to drush-3? Also, you can put php.ini in /etc/drush or $HOME/.drush, but not /etc/.drush, so the output you are showing above for drush status is in theory impossible.
I recommend trying again with a fresh copy of the HEAD branch of drush.
Comment #9
PI_Ron commentedHi Greg,
Thanks for that suggestion, that removed the issues I was having.
Its actually printing some different errors now, if this needs to be in another thread please advise.
run: drush up status