Opened 2 months ago

Closed 2 months ago

#14458 closed Bug/Something is broken (fixed)

drush/drupal version caused error

Reported by: k054 Owned by: Jamie McClelland
Priority: Medium Component: Tech
Keywords: Cc:
Sensitive: no

Description (last modified by k054)

Hey folks. I hope this message finds you well.

There seems to be a weird issue with the installed drush version within MFPL servers. Or maybe not just that, but maybe it playing weird with drush aliases.

Whenever we try to run a remote drush command, it partially works, but throws a bunch of warnings.

drush @gap uli
The external command could not be executed due to an application error.                                                                                                            [error]
Illegal string offset 'site' backend.inc:1032                                                                                                                                      [warning]
The command could not be executed successfully (returned: https://civi.global-action.org/user/reset/1/1548882658/XXXXXXXXXXXXXXXXX/login                 [error]
PHP Fatal error:  Uncaught TYPO3\PharStreamWrapper\Exception: Unexpected file extension in "phar:///usr/local/bin/drush/includes/.." in
/usr/local/share/drupal-7.62/misc/typo3/drupal-security/PharExtensionInterceptor.php:39
Stack trace:
#0 /usr/local/share/drupal-7.62/misc/typo3/phar-stream-wrapper/src/Behavior.php(72): Drupal\Core\Security\PharExtensionInterceptor->assert('phar:///usr/loc...', 'url_stat')
#1 /usr/local/share/drupal-7.62/misc/typo3/phar-stream-wrapper/src/Manager.php(83): TYPO3\PharStreamWrapper\Behavior->assert('phar:///usr/loc...', 'url_stat')
#2 /usr/local/share/drupal-7.62/misc/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(412): TYPO3\PharStreamWrapper\Manager->assert('phar:///usr/loc...', 'url_stat')
#3 /usr/local/share/drupal-7.62/misc/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(401): TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///usr/loc...', 'url_stat')
#4 [internal function]: TYPO3\PharStreamWrapper\PharStreamWrapper->url_stat('phar:///usr/loc...', 2)
#5 phar:///usr/local/bin in /usr/local/share/drupal-7.62/misc/typo3/drupal-security/PharExtensionInterceptor.php on line 39
, code: 255)
current() expects parameter 1 to be array, null given user.drush.inc:416                                                                                                           [warning]
parse_url() expects parameter 1 to be string, array given exec.inc:429                                                                                                             [warning]
 does not appear to be a resolvable hostname or IP, not starting browser. You may need to use the --uri option in your command or site alias to indicate the correct URL of this   [warning]
site.

or like this

drush @pipeline uli
The external command could not be executed due to an application error.                                                                                                            [error]
Illegal string offset 'site' backend.inc:1032                                                                                                                                      [warning]
The command could not be executed successfully (returned: http://lgbtpipeline.org/user/reset/1/1548882721/XXXXXXXXXXXXXXXXXXXXXXXX/login                        [error]
PHP Fatal error:  Uncaught TYPO3\PharStreamWrapper\Exception: Unexpected file extension in "phar:///usr/local/bin/drush/includes/.." in
/usr/local/share/drupal-7.62/misc/typo3/drupal-security/PharExtensionInterceptor.php:39
Stack trace:
#0 /usr/local/share/drupal-7.62/misc/typo3/phar-stream-wrapper/src/Behavior.php(72): Drupal\Core\Security\PharExtensionInterceptor->assert('phar:///usr/loc...', 'url_stat')
#1 /usr/local/share/drupal-7.62/misc/typo3/phar-stream-wrapper/src/Manager.php(83): TYPO3\PharStreamWrapper\Behavior->assert('phar:///usr/loc...', 'url_stat')
#2 /usr/local/share/drupal-7.62/misc/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(412): TYPO3\PharStreamWrapper\Manager->assert('phar:///usr/loc...', 'url_stat')
#3 /usr/local/share/drupal-7.62/misc/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(401): TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///usr/loc...', 'url_stat')
#4 [internal function]: TYPO3\PharStreamWrapper\PharStreamWrapper->url_stat('phar:///usr/loc...', 2)
#5 phar:///usr/local/bin in /usr/local/share/drupal-7.62/misc/typo3/drupal-security/PharExtensionInterceptor.php on line 39
, code: 255)
current() expects parameter 1 to be array, null given user.drush.inc:416                                                                                                           [warning]
parse_url() expects parameter 1 to be string, array given exec.inc:429                                                                                                             [warning]
 does not appear to be a resolvable hostname or IP, not starting browser. You may need to use the --uri option in your command or site alias to indicate the correct URL of this   [warning]
site.

here's some more ifo

https://www.drupal.org/project/drupal/issues/3026386

I already worked around it by installing drush 8.1.19-dev trough composer at the ~/.composer/vendor/bin folder, so this is not urgent, but we wanted to let you know.

Thanks!

Change History (12)

comment:1 Changed 2 months ago by k054

Description: modified (diff)
Summary: drushdrush/drupal version caused error

comment:2 Changed 2 months ago by JaimeV

Owner: set to Jamie McClelland
Status: newassigned

Lets get jamie to look at this one.

comment:3 Changed 2 months ago by Jamie McClelland

I can replicate (this only seems to affect running drush remotely), and it looks like loads of other people can also replicate this problem.

I've just experimented with upgrading from drupal 7.62 to 7.64 on one server (buffy) and it still doesn't work, but I get a different error:

parse_url() expects parameter 1 to be string, array given exec.inc:415                                                                                                               [warning]
parse_url() expects parameter 1 to be string, array given exec.inc:419                                                                                                               [warning]
ltrim() expects parameter 1 to be string, array given exec.inc:420                                                                                                                   [warning]
 does not appear to be a resolvable hostname or IP, not starting browser. You may need to use the --uri option in your command or site alias to indicate the correct URL of this     [warning]
site.

comment:4 Changed 2 months ago by Jamie McClelland

Upgrading to drush version 8.1.18 doesn't help - still getting the latest error.

comment:5 Changed 2 months ago by Jamie McClelland

Ah, success. Upgrading both the remote drush and my local drush to version 8.1.18 worked.

I tried downgrading drush on buffy back to 8.1.13 and it still worked - the trick is upgrading your local version of drush.

I suspect the winning combination is: upgrade remote site to 7.64 and upgrade local drush to 8.1.18.

I will push out the drupal upgrade tonight - since it tends to be disruptive (and requires a reboot of php fpm).

As long as you are running a local copy of drush that is 8.1.18 you should be ready to go after the drupal upgrade.

comment:6 Changed 2 months ago by k054

Thanks Jamie! That totally makes sense!

This happened to me under my Palante environment but I was not being able to replicate in my personal env, (which was still running drush 8.0.0-rc4) and connecting a site running 7.64 hosted at claudette, which runs drush 8.1.13.

I'm ok with closing this ticket but I'm not doing it myself bc you might want to take next steps among MFPL infrastructure.

Thanks!

Last edited 2 months ago by k054 (previous) (diff)

comment:7 in reply to:  3 Changed 2 months ago by Jack Aponte

Replying to https://id.mayfirst.org/jamie:

I can replicate (this only seems to affect running drush remotely), and it looks like loads of other people can also replicate this problem.

Thanks for all of your work on this, Jamie!

Initially we also thought that the problems here only affect drush running remotely. However, on January 30, the same day that our drush aliases started giving us trouble, the CiviCRM cron job that runs locally via drush for GAP on malcolm.mayfirst.org began to fail.

Here's the old cron job:

*/15 * * * * /usr/local/bin/drush -u 1 -r /home/members/globalaction/sites/global-action.org/web -l https://civi.global-action.org civicrm-api job.execute --quiet

It would fail every time with this error appearing in the Drupal log:

TYPO3\PharStreamWrapper\Exception: Unexpected file extension in "phar:///usr/local/bin/drush/commands/core/locale.d8.drush.inc" in Drupal\Core\Security\PharExtensionInterceptor->assert() (line 39 of /usr/local/share/drupal-7.62/misc/typo3/drupal-security/PharExtensionInterceptor.php).

The issue was resolved by switching the Civi cron job to use a separate version of Drush installed by k054 via Composer.

All of this seems to be related to issues with phar, which were changed in Drupal 7.63. If we look at the top of the MFPL-installed version of Drush on the server:

globalaction@malcolm:~/global-action.org/web$ head -n 10 /usr/local/bin/drush
#!/usr/bin/env php
<?php
/**
 * Generated by Box.
 *
 * @link https://github.com/herrera-io/php-box/
 */
if (class_exists('Phar')) {
Phar::mapPhar('drush.phar');
require 'phar://' . __FILE__ . '/drush';

Could the way that Drush is installed, at least on some MFPL servers, have something to do with this? And will your proposed fix address these other issues besides the remote drush problem, Jamie?

comment:8 Changed 2 months ago by Jamie McClelland

Hi Jack - I'm not really sure if what worked for the remote drush will work with the error you describe. However, I did just sign a tag - so in the next hour, all servers should be upgraded to both drupal 7.64 and drush 8.1.18. Let us know if you still get those errors.

Also, we now automatically restart php-fpm when we upgrade drupal, so that irritating problem of weird symlink related problems after a drupal upgrade should also be a thing of the past.

comment:9 in reply to:  8 Changed 2 months ago by Jack Aponte

Replying to https://id.mayfirst.org/jamie:

Hi Jack - I'm not really sure if what worked for the remote drush will work with the error you describe. However, I did just sign a tag - so in the next hour, all servers should be upgraded to both drupal 7.64 and drush 8.1.18. Let us know if you still get those errors.

Hmm--I still see Drush 8.1.13 in place on malcolm.mayfirst.org:

globalaction@malcolm:~$ which drush
/usr/local/bin/drush
globalaction@malcolm:~$ /usr/local/bin/drush --version
 Drush Version   :  8.1.13 

I do see the update to Drupal 7.64 in place for GAP.

Also, we now automatically restart php-fpm when we upgrade drupal, so that irritating problem of weird symlink related problems after a drupal upgrade should also be a thing of the past.

Good to know, thanks for the info! :)

comment:10 Changed 2 months ago by Jamie McClelland

Hi Jack,

drush seems to do some qustionable things with versioning. I think it is detecting that you have a version of drush in the directory you are executing the drush command in and, for reasons that are beyond me, using that version instead.

See what I mean:

0 malcolm:~# /usr/local/bin/drush --version
 Drush Version   :  8.1.18 

0 malcolm:~# su - globalaction
globalaction@malcolm:~$ /usr/local/bin/drush --version
 Drush Version   :  8.1.13 

globalaction@malcolm:~$ ./drush --version
 Drush Version   :  8.1.13 

globalaction@malcolm:~$ cd global-action.org/web/
globalaction@malcolm:~/global-action.org/web$ /usr/local/bin/drush --version
 Drush Version   :  8.1.18 

globalaction@malcolm:~/global-action.org/web$

wtf right??

comment:11 Changed 2 months ago by Jack Aponte

Whoa--you're right Jamie! /usr/local/bin/drush --version reports one thing in the home directory, where there's another version of drush installed (ugh didn't realize that!) and another in the system root directory:

globalaction@malcolm:~$ /usr/local/bin/drush --version
 Drush Version   :  8.1.13 

globalaction@malcolm:~$ cd /
globalaction@malcolm:/$ /usr/local/bin/drush --version
 Drush Version   :  8.1.18

Very strange! But yeah, I can see that Drush 8.1.18 is now installed at /usr/local/bin/drush.

I'm going to clean up that mess of drush installations, then see if the Civi cron errors still occur using /usr/local/bin/drush now that both it and Drupal have been updated.

comment:12 Changed 2 months ago by Jamie McClelland

Resolution: fixed
Status: assignedclosed

Great - I'm going to close this issue - feel free to re-open if you still have trouble getting it to work right.

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.