I have this error when trying to do update command:
The command could not be executed successfully (returned: Your command line PHP installation is too old. Drush requires at least PHP 5.2.0
, code: <em>0</em>)
An error occurred at function : drush_pm_post_update
If I just issue command like dl or any other without post processing, everything is fine.
Environment is:
[~ 22:57:34]$ which php
/usr/local/php5/bin/php
[~ 22:57:59]$ php -v
PHP 5.2.9 (cli) (built: Jun 12 2009 19:19:05)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies
[~ 22:58:26]$ env
TERM=xterm-color
SHELL=/bin/bash
SSH_CLIENT=81.18.62.42 63726 22
SSH_TTY=/dev/pts/3
USER=myself
MAIL=/home/myself/Maildir/
PATH=/usr/local/php5/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
LC_COLLATE=C
PWD=/home/myself
LANG=en_US.UTF-8
PS1=[\w \t]\$
SHLVL=1
HOME=/home/myself
_=/usr/bin/env
Everything is running fine except update which is followed by updatedb.
It used to run fine in september. After I changed for HEAD Dec.16 I have this error.
There are:
- php5 in /usr/local/php5/bin and
- php4 in /usr/bin/ which was default
I even setup drushrc.php with $options['php'] = '/usr/local/php5/bin/php';
and tried that also from command line with no luck.
I have no idea as how it could pick wrong PHP in drush_pm_post_update. I tried 'hacking' in some files but with no success.
I tried to hunt the bug but I am not that good.
However, version 2.1 is running fine!
Any clue?
Comment | File | Size | Author |
---|---|---|---|
#30 | dreamhost-2.patch | 1.09 KB | greg.1.anderson |
#26 | dreamhost.patch | 655 bytes | greg.1.anderson |
#24 | php-path.patch | 2.61 KB | greg.1.anderson |
Comments
Comment #1
MacMladen CreditAttribution: MacMladen commentedWith the latest version this is still the problem.
Does anyone knows why?
Comment #2
moshe weitzman CreditAttribution: moshe weitzman commentedupdate is doing a subshell for the updatedb part and is picking the wrong php. use the --php option to tell drush which php to use. usually this is not needed but it seems to be in your case. an alternative is to make sure that the right php is in your $PATH. if you are on a unix like OS, you can type `which php` to see what php you are using by default.
Comment #3
moshe weitzman CreditAttribution: moshe weitzman commentedComment #4
MacMladen CreditAttribution: MacMladen commentedI described environment and also making
drushrc.php
.Version from october 2.1 is working as it should be with subshell (I know that it is subshelled and that it is picking /usr/local/bin/php) and you could see in a block that it is in unix environment.
I can only repeat (that is to confirm) that problem still exists in latest HEAD 09.jan.2010 and that 2.1 version runs it fine.
This could be just my configuration but I believe that somewhere something is changed from 2.1 to HEAD-2010-01-09 that is breaking things (and people get killed :)
Now I do have a change:
--php
switch doesnotwork, I said I tried that in in command line anddrushrc.php
where it is not documented and does not work.Suggestion: please insert --php directive in
drushrc.php
I'd love that being fixed (probably I could find way around) and to use latest version.
Comment #5
heyyo CreditAttribution: heyyo commentedI have exactly the same problem, it was working with stable release but not with the last dev.
I also tried to use the --php in command line and drushrc.php but with no luck. Is there any example on how to use it ?
Regards
Comment #6
Andrey Zakharov CreditAttribution: Andrey Zakharov commented(:few:)
patch is dirty and fastest
Of course this code just need some refresh :)
begin from
But tool is GREAT!
Comment #7
anarcat CreditAttribution: anarcat commentedDrush HEAD does use the --php option in the shell wrapper. You seem to have a very particular setup that warrants rolling out your own wrapper script or specifying --php on the commandline.
I do find the idea of supporting specification of the binary from the environment, but I'm worried about security issues that might arise from this practice.
Otherwise I'm marking this "needs info" because: a) #6 obviously applies to 2.1 while the OP reported this on HEAD, b) #4 is unclear on what works and what doesn't.
Before requesting help on PHP path issues, please mention:
1. which operating system you're using
2. which shell
3. where PHP version(s) are installed
4. which drush version you're trying
5. the output of drush test drush --debug
Thanks
Comment #8
flickerfly CreditAttribution: flickerfly commentedI've had need of specifying my own php config to drush. I found this worked out fine:
On line 40 of the drush/drush (the wrapper)
elif [$PHPRC] ; then
# If PHPRC is set we run with straight php with a custom config directory.
/usr/bin/env php -c $PHPRC $SCRIPT_PATH "$@"
Then I just set the PHPRC variable used by other PHP stuff for such things to the directory of my php config and it was happy. My reason for doing this was different, but found this when searching out duplicates. Perhaps it is helpful?
Comment #9
butler360 CreditAttribution: butler360 commentedSubscribing
Comment #10
tim.plunkettWhen I run phpversion() in another php file, it comes back 5.2.12, but inside drush it thinks it's 4.4.9. Very frustrating.
Oh, and I'm using drush-HEAD.
Comment #11
moshe weitzman CreditAttribution: moshe weitzman commented/usr/local/php5/bin//php
why double slash before php?you can setup an alias like
Comment #12
tim.plunkettI'm not sure why there is a double slash, I don't understand dreamhost enough to explain that.
I set up that alias in my .bashrc file, to no avail.
Even if I call it directly:
And I even tried modifying drush.php to include phpversion() in the die() message, and it told me that my PHP version is 4.4.9. Infuriating!
Comment #13
moshe weitzman CreditAttribution: moshe weitzman commentedthe update command uses backend_invoke to do the updatedb part. thats where your php is getting confused. for now, just separate the two steps into different commands.
/usr/local/php5/bin//php ~/bin/drush/drush.php updatecode
/usr/local/php5/bin//php ~/bin/drush/drush.php updatedb
this technique won't help for remote commands but you have until 3.0 to figure that out.
Comment #14
tim.plunkettGreat, running drush upc and drush updb separately works great. Is there anything I can do to help with fixing this issue for everyone?
Comment #15
MacMladen CreditAttribution: MacMladen commentedAs usual, #4 looked simple and clear to author.
I wanted to say that drush-All-Versions-HEAD from 2010-01-08 worked with
--php
switch once I figured out how to put it the right way.So, for all of you on Dreamhost, my commarades, here is what is working with drush-All-Versions-HEAD.tar.gz from 2010-01-08.
alias dr='/home/mladen/drush/drush --php=/usr/local/php5/bin/php'
and it is working as it should be, both with spawned commands (like updatedb after update) and with site aliases.
It does have some problems with multiple multisite instalation (I have 4 different multisite instalations with alias on main modules and themes repository - I know it looks like complicated but it is logical) but that is not being discussed here as I still am not sure what is exactly happening.
However, dear moshe weitzman and anarcat, the latest version 3.0 alpha is not working even with that
--php
directive.I am not that good to see security implications, but even though I did put it in the
path
,which
is pointing to right version, but just like with others, it is picking wrong version. How - I have no clue.--php
that is working (and overriding) for those that need to have default version 4.--php
should be documented with example so people could see syntax (not everyone is command line experienced)--php
should be included as directive (with all others) in global (for all sites) and in[site aliases]
(for particular alias) indrushrc.php
Comment #16
greg.1.anderson CreditAttribution: greg.1.anderson commentedPart of this might be my fault. There are places where drush will compose %drush-script from %drush; it should never do this. This might be interfering with other processing in backend invoke for instances where those code paths are traversed.
I'll look into this shortly; I cannot today, but wanted to put in a quick note in case someone else did.
Comment #17
anarcat CreditAttribution: anarcat commentedHi,
So it seems this issue is still relevant and the required information *was* provided so I'm bumping this back to the active status, thank you for your feedback. I am taking the opportunity here to clarify the title of this issue to better describe the issue I understand you guys are having.
First, I must note that I am not on Dreamhost and do not have access to such a convoluted setup. And while I think it's great that we strive to make Drush work everywhere, you guys need to understand that it will simply not be possible on broken setup. I am not saying that Dreamhost is broken, but it sure looks messy.
Now to answer #15 directly, let me first say that I actually had a lot of trouble understanding #4, and I still have problems figuring out what exactly is the problem, by those descriptions. I'm sorry about that, maybe it's a language issue (my native language is not english). I must thank you for answering promptly with the required details however. To answer your specific requirements however:
I'm not sure I understand that, but it was my understanding that --php was working well. However, it's a hack: the key assumption that drush needs to make to function properly is that the "php" executable in the path is the right PHP, and the basic thing people should do when they start using Drush is making sure that works, by modifying their $PATH if necessary.
I think we all agree the problem should be solved here, although I'm not sure what you mean by "issuing two commands".
I *think* --php is documented in the --help output, so I don't see where else it should be documented. Furthermore, I think it's safe to assume that the Drupal *Shell* (drush) is for people that have *some* experience with the commandline. People can just use the regular Drupal interface if they cannot grok the shell.
That is a good idea. You mentionned earlier problems of defining --php in a drushrc: is it because it's not working (if so please provide an example drushrc) or just because it's not documented?
Thank you again for your perseverance, I think it's important to really fix this issue before 3.0 gets settled, so I encourage you to keep on testing and trying out our patches when they come. :)
@greg - I may have some time to look at this today.
Comment #18
greg.1.anderson CreditAttribution: greg.1.anderson commentedThanks -- the thing I mention is more likely to cause problems for remote command execution, and in any event is only a problem when using site aliases. I'll open a separate issue.
Comment #19
anarcat CreditAttribution: anarcat commentedreplying to #10 more directly now: it looks like drush is picking up your *other* PHP installation (because it sure looks like the server has PHP installed *twice*, which I find kind of silly nowadays). It's unclear to me what "drush test-drush --debug" called: is drush an alias? or is the drush shell wrapper in your path? or is drush.php symlinked to drush somewhere in the path? (Those are all configurations I have seen in the wild.)
Could you try again running test-drush using: drush.php test-drush --debug (as opposed to just drush)?
I have the feeling you simply need to bypass the shell wrapper, which probably picks up your older, but properly configured PHP executable.
Comment #20
tim.plunkettAlso, I currently have drush aliased to the wrapper, and /usr/local/php5/bin/ is in my PATH.
Comment #21
anarcat CreditAttribution: anarcat commentedOkay, that's fascinating... The way drush.php runs is through the #! header, the first line of the script, which says:
Normally, this should do the same $PATH lookup as your shell (unless you have an alias on php). So it seems that running php from the commandline and through env doesn't yield the same results.
Can you try the following:
Sorry for the to and fro, but I am really puzzled by this, cannot reproduce or figure out how to fix this...
Comment #22
greg.1.anderson CreditAttribution: greg.1.anderson commentedAgree with anarcat.
Is 'php' an alias on dreamhost?
What is the exact contents of your $PATH? Could you set $PATH such that php5 appears first?
P.S. The reason you have a double-slash in #10 is that you have "/usr/local/php5/bin/" instead of "/usr/local/php5/bin" in your path. Double slashes are innocuous, though.
Comment #23
MacMladen CreditAttribution: MacMladen commentedOK, here I am for all Dreamhost peculiar ;)
Please be patient as I'll try to make myself as clear as possible (English is not my native either and sometimes we all get too deep in our thoughts to express ourselves).
I also hope that I am talking for all of us on Dreamhost but possibly also for someone else. This will be big one and I'll use some pseudo syntax.
[The essence]
The exact problem is not calling
drush
(by whatever method) it is happening whendrush
is calling itself e.g. after update it is calling itself (spawning) and then it is when it calls wrong version. We all have php in our path and everything is set as it should be (at least to my level of knowledge), please check environment at the top carefully, there arewhich php
andenv
(you see path and default execution is command, not alias).We should all bear in mind that sometimes server admin give other environment for commands that we run, especially to those commands that are spawned by our commands. I know that but I do not know how to test. I did put some php code that prints
php -v
just to find out where is change happening and it is in second call (when update is calling updatedb).This answers some questions but if it is still not clear, please ask more specifically.
@ #17 - 1
--php
was fixing a version problem for me (us on Dreamhost) on HEAD but not anymore in latest 3.0 alpha 1. If you wish I could give you SSH account to try it for yourself with some test drupal installation, just mail me.@ #17 - 2
It was for #13 suggestion to use two commands, however, I did not notice words for now... until resolved. There mosche clearly points where the problem lies.
@ #17 - 3
Well.. kinda. Sometimes arguments are divided by space (for all commands like
drush -l bluefish.rs -r ~/drupal6
and for this syntax is--php=/abs/path/to
. I am not inexperienced but still,help
does not output anything when you ask specifically for--php
, just general help, and I had to try several "standards" for arguments to get to this one. So I just wanted to point out to include this sample line to help,--php=/abs/path/to
it is not that hard :)@ #17 - 4
As I understood,
--php
is not indrushrc.php
(neither in[site aliases]
) by design and I am pledging to include it.I was reading in
example.drushrc.php
thatdrushrc.php
files will be read from locations in that order and merged.If someone (like myself) is having few multi site installations (I have one old multi installation, one new that is cleaner organized and few drupal distros like openpublish and atrium, all in their own directories) and I want to use
drushrc.php
with[site aliases]
to shorten commands for maintenance, I would use one maindrushrc.php
with defaults for all of them (like calling specific php) and in each multi installation to have their[site aliases]
with specifics.I was not thinking of using it for remote but for shortening commands (like
dr blue up
for/home/macmladen/drush/drush --php=/usr/local/php5/bin/php -l bluefish.rs -r ~/drupal6 updatecode
)I have tried that but it is not merging as it is said in
drushrc.php
but I did not looked in the case too deep as I am primarily bugged with--php
.I am happy that you want to include
--php
indrushrc.php
and I am ready to help. If it works for me, it will work for any nuts out there :D@ #19
This is output with HEAD version from 2010-01-08
This is output with 3.0 alpha 1 version from 2010-01-28
This is output with
drush.php
3.0 alpha 1 version from 2010-01-28@ #21
env
is set properly as you could see in initial post and shell is picking rightphp
.@ #22
PATH
is also set ok, again, look at initial post andphp
is not alias.Comment #24
greg.1.anderson CreditAttribution: greg.1.anderson commentedTry this patch. This fixes some problems, but probably not the one you're seeing, so don't be frustrated if this gives no change in behavior.
Try calling drush with the --php arg. It's still supported. You can also specify the php path via site aliases if you define '%drush-script' in path aliases to be '/path/to/php /path/to/drush.php --php=/path/to/php'.
The most helpful thing would be to know why these two things are different on dreamhost:
php drush.php command
drush.php command
I may take you up on your offer for dreamhost access, but don't have time to look at it now.
Comment #25
MacMladen CreditAttribution: MacMladen commentedOh my... this is curse of open source + working for community :)
Briefly: no it does not change anything (the patch).
1. I used latest drush-HEAD from CVS to be able to use patch
2. I applied patch but still everything is broken (people dying, etc..)
BUT.. I've done testing and here are combinations and results (may be complicated, read carefully):
/path/to/drush.php --php=/path/to/php -l bluefish.rs -r /path/to/drupal up
is not working (too old..)/path/to/php /path/to/drush.php -l bluefish.rs -r /path/to/drupal up
is not working (too old..)/path/to/php /path/to/drush.php --php=/path/to/php -l bluefish.rs -r /path/to/drupal up
In the last case it is not necessary to have full path, just
php /path/to/drush.php ... etc
is enough to work.There is difference in just
./drush.php
invocation andphp ./drush.php
: first drop immediately, second only on callingupdatedb
if there is no--php
switch which brings me to conclusion thatenv
is different for user and for script, security I guess.Update: i made a
cp drush.php d2.php
and changed fromenv php
topath/to/php
and still it drops out in first line, like:Comment #26
greg.1.anderson CreditAttribution: greg.1.anderson commentedDreamhost is wonky; that last test should always work, I would think. Since #3 works for you, I guess that at the very least we have a usable workaround. I committed #24 as a general improvement.
The following patch should make "./drush" work better on Dreamhost. Does anyone see any reason why we should not commit this in the general case? This is presuming that MacMladen or tim.plunkett can confirm that it actually improves things for Dreamhost; I expect it should.
Comment #27
greg.1.anderson CreditAttribution: greg.1.anderson commentedThe other question that comes to mind is how do you set your PATH on dreamhost? If you set it by typing "PATH=/path/to/php:$PATH" every time you start your shell, it could simply be that Dreamhost is reseting your entire environment every time it exec's a shell script. This is as suggested in #25, but it would be odd if Dreamhost was doing anything other than resetting to a default environment.
If this is the case, then the patch in #26 won't help at all. You could potentially fix your Dreamhost install by configuring your PATH in some bash rc file that Dreamhost executes on startup. See man bash for defaults, but I won't take it for granted at this point that Dreamhost hasn't changed this behavior as well.
In any event, since 3. works in #25, perhaps there is nothing else to do here.
Comment #28
tim.plunkettThe patch in #27 works,
drush test-drush --debug
comes back clean, as well asdrush up
.I have my PATH set within my .bashrc.
(
export PATH=/usr/local/php5/bin:$PATH
)Comment #29
greg.1.anderson CreditAttribution: greg.1.anderson commentedIf there are no objections, I'm going to commit #26. This should not interfere with the general case, and it makes life much better for the Dreamhost folks.
Comment #30
greg.1.anderson CreditAttribution: greg.1.anderson commented#24 can cause problems in some rare cases; for example:
drush remote-alias update
The problem is that the --php flag is passed to the remote machine, which will cause a problem if php is stored in a different location. The solution (attached) is to omit the php flag from the redispatch options unless it is part of the drush command.
Comment #31
greg.1.anderson CreditAttribution: greg.1.anderson commentedI logged on to the Dreamhost account that MacMladen graciously provided and did some experiments. I discovered essentially what has already been surmised. For any executable file on dreamhost that ends in ".php", the "#!/path/to/script" line is ignored, and the php that Dreamhost wants you to run (/usr/local/bin/php) is executed. $PATH is ignored.
If you rename "drush.php" to "drush.sh", then you can run it successfully. Not that this is useful, since drush expects it to be "drush.php", but it is a useful test.
I don't know if it is a standard Linux feature to be able to set the path to an executable based on the file extension, or if Dreamhost has simply hacked their shell. I've read the bash manual many times, but did not re-read it tonight to check.
In any event, if no one has anything further to add on this subject, I'll go ahead and commit #30. It seems to work out okay, and as far as I know at the moment, there is no workaround to fix Dreamhost.
Comment #32
greg.1.anderson CreditAttribution: greg.1.anderson commentedCommitted #30.
Comment #33
MacMladen CreditAttribution: MacMladen commentedJust downloaded
drush-HEAD
and I can confirm that everything is working as expected.Without
--php
override just plainpath/to/drush site up
done everything right even themes that used to bug me with needs to be updated and then error cannot .. (whatever).Thanks and I hope Dreamhosters are rejoicing :)
Comment #34
flickerfly CreditAttribution: flickerfly commentedUnless I misunderstand #33, the postponed status was an accident as the response seems to indicate it is fixed.
Comment #36
toddgee CreditAttribution: toddgee commentedFWIW, I maintain a lot of Drupal sites on DreamHost and have written a set of bash shell scripts for Drupal administration. They integrate with Drush (for the updatedb command) but, IMHO, are more useful for managing large numbers of Drupal scripts.
See toddgee.com/drupalScripts
also toddgee.com/tag/dreamhost
todd
Comment #37
AdrianB CreditAttribution: AdrianB commentedI'm not using using Dreamhost (I'm using JaguarPC) but I get this error when running
drush updatedb
using All-versions-3.0:The command could not be executed successfully (returned: sh: /home/[username]/bin/drush/drush.php: Permission denied, code: <em>126</em>)
Before I open a new issue, is this related to this Dreamhost issue or something else?
Comment #38
frobI am using 3.1 released 6-21-10 and I get the same issue, was this only committed to the dev release or is this in 3.1?
Strange thing is I only get this error when I use drush with sudo.
Comment #39
greg.1.anderson CreditAttribution: greg.1.anderson commentedDreamhost may have changed their security policies; I can't remember if I tried with sudo. In any event, #30 was committed and is still in 3.1. Re-open if you can isolate the source of the problem and it looks like something drush could address.
Comment #40
frobI will see what I can do. This might be a server issue and I have opened the issue with Dreamhost as well.