drush up drupal fails on _drush_recursive_copy - drupal

I am not able to upgrade to drupal 8.6.2 using drush 8.1.17. Unfortunately, drush does not provide the reason behind its failure. I have no clue of what do do next, and even how to debug it further. Any help is appreciated, thanks in advance.
It follows an excerpt of the command $ drush --debug up drupal, you can find the (almost) complete log here (I only removed the untar output to have a smaller file such that can be pasted on pastebin)
Calling chdir(/var/www/html) [94.7 sec, 14.02 MB] [debug]
Calling is_readable(/tmp/drush_tmp_1539963315_5bc9f9b34e37c/drupal-8.6.2) [94.7 sec, 14.02 MB] [debug]
Calling is_writable(/var/www/html) [94.7 sec, 14.02 MB] [debug]
Calling rename(/tmp/drush_tmp_1539963315_5bc9f9b34e37c/drupal-8.6.2, /var/www/html/drupal-8.6.2) [94.7 sec, 14.02 MB] [debug]
Calling _drush_recursive_copy(/tmp/drush_tmp_1539963315_5bc9f9b34e37c/drupal-8.6.2, /var/www/html/drupal-8.6.2) [94.7 sec, 14.02 MB] [debug]
Unable to copy /tmp/drush_tmp_1539963315_5bc9f9b34e37c/drupal-8.6.2 to /var/www/html/drupal-8.6.2. [116.8 sec, 14.02 MB] [error]
Unable to move /tmp/drush_tmp_1539963315_5bc9f9b34e37c/drupal-8.6.2 to /var/www/html/drupal-8.6.2. [116.8 sec, 14.02 MB] [error]
Updating project drupal failed. Attempting to roll back to previously installed version. [116.8 sec, 14.02 MB] [error]
Returned from hook drush_pm_updatecode [116.8 sec, 13.92 MB] [debug]
Rolling back update of Drupal core code ... [116.8 sec, 13.92 MB] [notice]
Verifying signature for svn version control engine. [116.8 sec, 13.92 MB] [debug]
Executing: svn info drupal-8.6.2
sh: 1: svn: not found
Verifying signature for bzr version control engine. [117.1 sec, 10.88 MB] [debug]
Executing: bzr root drupal-8.6.2
sh: 1: bzr: not found
Calling drush_delete_dir(/var/www/html/drupal-8.6.2, 1) [117.2 sec, 10.88 MB] [debug]
Calling is_readable(/var/www/drush-backups/the_site_com/20181019153440/drupal) [121.8 sec, 10.88 MB] [debug]
Calling is_writable(/var/www/html) [121.8 sec, 10.88 MB] [debug]
Calling rename(/var/www/drush-backups/the_site_com/20181019153440/drupal, /var/www/html/drupal-8.6.2) [121.8 sec, 10.88 MB] [debug]
Backups were restored successfully. [121.8 sec, 10.88 MB] [ok]
A couple of info that might be useful:
root#host:/var/www/html# su www-data -s /bin/bash -c 'drush --version'
Drush Version : 8.1.17
root#host:/var/www/html# su www-data -s /bin/bash -c 'drush core-status'
Drupal version : 8.5.3
Site URI : http://default
Database driver : mysql
Database hostname : the-database-hostname
Database port :
Database username : the-database-username
Database name : the-database-name
Database : Connected
Drupal bootstrap : Successful
Drupal user :
Default theme : mytheme
Administration theme : seven
PHP configuration : /usr/local/etc/php/php.ini
PHP OS : Linux
Drush script : /usr/local/bin/drush
Drush version : 8.1.17
Drush temp directory : /tmp
Drush configuration :
Drush alias files :
Install profile : standard
Drupal root : /var/www/html
Drupal Settings File : sites/default/settings.php
Site path : sites/default
File directory path : sites/default/files
Temporary file directory path : /tmp
Sync config path : sites/default/files/config_xeVhGsWgDSMcUJNlA97zQiNNekC93e2MhX5aEtO5UcOtKQnwq7fjEB9K6Bk15kj53APj6h8Ibg/sync

That's probably very easy to explain.
Drupal 8 now requires Drush 9.
See the chart on http://docs.drush.org/en/master/install. D8.3- means with Drush 8 your Drupal can not be greater than or equal to 8.3.
I don't know how far you already got with your project. But you may consider to restart with drupal-composer/drupal-project which already always will have the right Drush version as local dependency on board. And it will also tell you to not update Drupal with Drush anymore. Do that with Composer instead.

Related

Drush in ddev returns BadRequestHttpException

When I try and run any drush commands within ddev (even just drush itself), I get a BadRequestHttpException. My drush version is 11.0.9 . I have tried ddev restart, ddev stop/start, and ddev delete; all have the same outcome. I ran ddev composer install too and no difference. It was working at some time, but maybe a week or so ago it just stopped. Here is the verbose response from ddev drush -vvv (sorry for the large output wall):
ddev drush -vvv
[preflight] Config paths: /var/www/html/vendor/drush/drush/drush.yml
[preflight] Alias paths: /var/www/html/web/drush/sites,/var/www/html/drush/sites
[preflight] Commandfile search paths: /var/www/html/vendor/drush/drush/src,/var/www/html/drush
[info] Starting bootstrap to max [0.8 sec, 3.2 MB]
[debug] Trying to bootstrap as far as we can [0.8 sec, 3.2 MB]
[info] Drush bootstrap phase: bootstrapDrupalRoot() [0.8 sec, 3.2 MB]
[info] Change working directory to /var/www/html/web [0.8 sec, 3.2 MB]
[info] Initialized Drupal 9.3.14 root directory at /var/www/html/web [0.81 sec, 3.27 MB]
[info] Drush bootstrap phase: bootstrapDrupalSite() [0.82 sec, 3.28 MB]
In DrupalKernel.php line 372:
[Symfony\Component\HttpKernel\Exception\BadRequestHttpException]
Exception trace:
at /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php:372
Drupal\Core\DrupalKernel::findSitePath() at /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php:109
Drush\Boot\DrupalBoot8->confPath() at /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php:158
Drush\Boot\DrupalBoot8->bootstrapDoDrupalSite() at /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot.php:158
Drush\Boot\DrupalBoot->bootstrapDrupalSite() at /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php:291
Drush\Boot\BootstrapManager->doBootstrap() at /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php:477
Drush\Boot\BootstrapManager->bootstrapMax() at /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php:412
Drush\Boot\BootstrapManager->bootstrapToPhaseIndex() at /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php:384
Drush\Boot\BootstrapManager->bootstrapToPhase() at /var/www/html/vendor/drush/drush/src/Boot/BootstrapHook.php:32
Drush\Boot\BootstrapHook->initialize() at /var/www/html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:44
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->doInitializeHook() at /var/www/html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:36
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook() at /var/www/html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:29
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize() at /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php:145
Consolidation\AnnotatedCommand\CommandProcessor->initializeHook() at /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:335
Consolidation\AnnotatedCommand\AnnotatedCommand->initialize() at /var/www/html/vendor/symfony/console/Command/Command.php:221
Symfony\Component\Console\Command\Command->run() at /var/www/html/vendor/symfony/console/Application.php:1027
Symfony\Component\Console\Application->doRunCommand() at /var/www/html/vendor/symfony/console/Application.php:273
Symfony\Component\Console\Application->doRun() at /var/www/html/vendor/symfony/console/Application.php:149
Symfony\Component\Console\Application->run() at /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php:124
Drush\Runtime\Runtime->doRun() at /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php:51
Drush\Runtime\Runtime->run() at /var/www/html/vendor/drush/drush/drush.php:72
require() at /var/www/html/vendor/drush/drush/drush:3
include() at /var/www/html/vendor/bin/drush:112
Failed to run drush -vvv: exit status 1
Any guidance would be helpful.
So what the issue turned out to be was the port in the settings.ddev.php didn't match the port that was registered to the database - it didn't match what was returned with ddev describe. I deleted the settings.ddev.php file and ran a new ddev pull with my provider to regenerate the settings file and that resynced the ports and resolved the issue.

Drush fails with ReflectionException: Class Drush\Sql\Sql7 does not have a constructor

I have followed instructions on http://docs.drush.org/en/master/install/ to install Drush (tried both global and individual options).
When I cd to the Drupal site root and type "drush status" I get the following:
Drupal version : 7.34
Site URI : http://default
PHP executable : /usr/bin/php
PHP configuration : /etc/php.ini
PHP OS : Linux
Drush script : /root/.composer/vendor/drush/drush/drush.php
Drush version : 7.0.0
Drush temp directory : /tmp
Drush configuration :
Drush alias files :
Drupal root : /var/www/site_dev
Site path : sites/default
When I type "drush cc all" I get:
No Drupal site found, only 'drush' cache was cleared.
'all' cache was cleared.
When I type "drush sqlc" I get:
exception 'ReflectionException' with message 'Class Drush\Sql\Sql7 does not have a constructor, so you cannot pass any constructor [error]
arguments' in /root/.composer/vendor/drush/drush/includes/drush.inc:113
Stack trace:
#0 /root/.composer/vendor/drush/drush/includes/drush.inc(113): ReflectionClass->newInstanceArgs(Array)
#1 /root/.composer/vendor/drush/drush/commands/sql/sql.drush.inc(605): drush_get_class('Drush\Sql\Sql', Array, Array)
#2 /root/.composer/vendor/drush/drush/commands/sql/sql.drush.inc(588): drush_sql_get_version()
#3 /root/.composer/vendor/drush/drush/commands/sql/sql.drush.inc(454): drush_sql_get_class()
#4 [internal function]: drush_sql_cli()
#5 /root/.composer/vendor/drush/drush/includes/command.inc(368): call_user_func_array('drush_sql_cli', Array)
#6 /root/.composer/vendor/drush/drush/includes/command.inc(219): _drush_invoke_hooks(Array, Array)
#7 [internal function]: drush_command()
#8 /root/.composer/vendor/drush/drush/includes/command.inc(187): call_user_func_array('drush_command', Array)
#9 /root/.composer/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(62): drush_dispatch(Array)
#10 /root/.composer/vendor/drush/drush/drush.php(70): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#11 /root/.composer/vendor/drush/drush/drush.php(11): drush_main()
#12 {main}
It strikes me that the problem has something to do with MySQL (because the status doesn't list the DB parameters), but I can't figure it out. Under sites there is only default folder, so it's not a multisite installation.
Can anyone advise what's wrong please?
UPDATE
I have upgraded PHP to 5.5.27 and reinstalled Drush 7.0.0.
Following an advice here I deleted my.cnf from the home folder and after that "drush sqlc" started to work, however when I type "drush -v -d status" it gives me:
Starting Drush preflight. [0.01 sec, 2.08 MB] [preflight]
Cache HIT cid: 7.0.0-commandfiles-0-81cc86c1995ab7206f383ec28ad43baf [0.01 sec, 2.14 MB] [debug]
Bootstrap to phase 0. [0.07 sec, 6.08 MB] [bootstrap]
Drush bootstrap phase : bootstrap_drupal_root() [0.08 sec, 6.43 MB] [bootstrap]
Initialized Drupal 7.34 root directory at /var/www/site_dev [0.08 sec, 6.43 MB] [notice]
Find command files for phase 1 (max=7) [0.08 sec, 4.48 MB] [debug]
Cache HIT cid: 7.0.0-commandfiles-1-a0882f4af91e1d6b72794cc62bb1b558 [0.08 sec, 4.49 MB] [debug]
Drush bootstrap phase : bootstrap_drupal_site() [0.08 sec, 4.49 MB] [bootstrap]
Initialized Drupal site default at sites/default [0.08 sec, 4.5 MB] [notice]
Find command files for phase 2 (max=7) [0.09 sec, 4.5 MB] [debug]
Cache HIT cid: 7.0.0-commandfiles-2-f17fc6bdab2f74278df75194ca483893 [0.09 sec, 4.5 MB] [debug]
Drush bootstrap phase : bootstrap_drupal_configuration() [0.09 sec, 4.5 MB] [bootstrap]
Find command files for phase 3 (max=7) [0.09 sec, 4.51 MB] [debug]
sql-query: SELECT 1; [0.09 sec, 4.62 MB] [status]
Executing: mysql --defaults-extra-file=/tmp/drush_CKiVHd --database=site_dev --host=localhost --silent < /tmp/drush_DG1fIs
1
Drush bootstrap phase : bootstrap_drupal_database() [0.1 sec, 4.62 MB] [bootstrap]
Successfully connected to the Drupal database. [0.11 sec, 5.13 MB] [bootstrap]
Find command files for phase 4 (max=7) [0.11 sec, 5.13 MB] [debug]
Drush bootstrap phase : bootstrap_drupal_full() [0.11 sec, 5.13 MB] [bootstrap]
Cannot modify header information - headers already sent by (output started at /root/.composer/vendor/drush/drush/includes/output.inc:38)[warning]
common.inc:698 [0.96 sec, 31.9 МБ]
Drush command terminated abnormally due to an unrecoverable error.
Sounds like it could be this issue: 7.x does not work with PHP 5.3.3.
There is a solution provided in this comment:
The base class SqlVersion class does not have a constructor and yet an
empty array is passed into its descendant (Sql6 or Sql7).
To workaround this, the line:
return $reflectionClass->newInstanceArgs($constructor_args);
should be replaced with:
return !empty($constructor_args) ?
$reflectionClass->newInstanceArgs($constructor_args) :
$reflectionClass->newInstanceArgs();
Alternatively you can upgrade PHP v5.4 or higher.
Or, you can downgrade Drush to 6.x.
If you're running this site in your local (dev) environment (hard to tell from the question ...)
then try changing the database host in Drupal's settings.php file from "localhost" to "127.0.0.1".
If you're working on Windows, you need to verify that your PATH Variable for MYSQL is properly set. I had the problem when I had upgraded my WAMP.
Example like this : C:\wamp\bin\mysql\mysql5.6.17\bin

Riak 1.3.1 will not start on lucid, Ec2 instance

I have installed riak (apt-get) on an EC2 instance, lucid, amd64 with libssl.
When running riak start I get:
Attempting to restart script through sudo -H -u riak
Riak failed to start within 15 seconds,
see the output of 'riak console' for more information.
If you want to wait longer, set the environment variable
WAIT_FOR_ERLANG to the number of seconds to wait.
Running riak console:
Exec: /usr/lib/riak/erts-5.9.1/bin/erlexec -boot /usr/lib/riak/releases/1.3.1/riak
-embedded -config /etc/riak/app.config
-pa /usr/lib/riak/lib/basho-patches
-args_file /etc/riak/vm.args -- console
Root: /usr/lib/riak
Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:2:2] [async-threads:64] [kernel-poll:true]
/usr/lib/riak/lib/os_mon-2.2.9/priv/bin/memsup: Erlang has closed.
Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,riak_core, {shutdown,{riak_core_app,start,[normal,[]]}}}"}
Crash dump was written to: /var/log/riak/erl_crash.dump
Kernel pid terminated (application_controller) ({application_start_failure,riak_core, {shutdown,{riak_core_app,start,[normal,[]]}}})
The error logs:
2013-04-24 11:36:20.897 [error] <0.146.0> CRASH REPORT Process riak_core_handoff_listener with 1 neighbours exited with reason: bad return value: {error,eaddrinuse} in gen_server:init_it/6 line 332
2013-04-24 11:36:20.899 [error] <0.145.0> Supervisor riak_core_handoff_listener_sup had child riak_core_handoff_listener started with riak_core_handoff_listener:start_link() at undefined exit with reason bad return value: {error,eaddrinuse} in context start_error
2013-04-24 11:36:20.902 [error] <0.142.0> Supervisor riak_core_handoff_sup had child riak_core_handoff_listener_sup started with riak_core_handoff_listener_sup:start_link() at undefined exit with reason shutdown in context start_error
2013-04-24 11:36:20.903 [error] <0.130.0> Supervisor riak_core_sup had child riak_core_handoff_sup started with riak_core_handoff_sup:start_link() at undefined exit with reason shutdown in context start_error
I'm new to Riak and basically tried to run through the "Fast Track" docs.
None of the default core IP settings in the configs have been changed. They are still set to {http, [ {"127.0.0.1", 8098 } ]}, {handoff_port, 8099 }
Any help would be greatly appreciated.
I know this is old but there is some solid documentation about the errors in the crash.dump file on the Riak site.

Setup of flex units on linux

I am working on a project using Flex and until now we are using Windows to run flex unit tests for the modules/artifacts that require flex environment. Because of given dependencies, it is difficult to automatize anything because I have to swithch between linux/windows when running those maven tests.
I have made an effort to try to make flex units tests run on linux, but have not succedded [yet]. Here is small part of the stack trace from maven clean test -X on a flex project.
[INFO] Flexmojos 3.8
[INFO] Apache License - Version 2.0 (NO WARRANTY) - See COPYRIGHT file
[INFO] Running tests /root/trunk/flex-project/flex-surface/flex-surface-common/flex-surface-common-flex/target/test-classes/TestRunner.swf
[DEBUG] [org.sonatype.flexmojos.test.monitor.AsVmPing] opened server socket on port 13540
[DEBUG] [org.sonatype.flexmojos.test.monitor.ResultHandler] opened server socket on port 13539
[DEBUG] [LAUNCHER] ASVmLauncher starting
[DEBUG] [LAUNCHER] exec: /usr/bin/flashplayer - /root/trunk/flex-project/flex-project-arbeidsflate/flex-surface-common/flex-surface-common-flex/target/test-classes/TestRunner.swf
[DEBUG] [LAUNCHER] Creating process
[WARNING] [LAUNCHER] Using xvfb-run to launch headless tests
[DEBUG] [LAUNCHER] Process created java.lang.UNIXProcess#1a6c088
[DEBUG] [MOJO] launcher RUNNING
[DEBUG] [MOJO] pinger STARTED
[DEBUG] [MOJO] resultHandler STARTED
[DEBUG] [LAUNCHER] Output pumpers ON
[DEBUG] [LAUNCHER] Waiting for flashplayer termination
[DEBUG] [LAUNCHER] Flashplayer closed
[DEBUG] [LAUNCHER] Unexpected return code 1
[DEBUG] [SYSERR]: mktemp: cannot create temp file /tmp/Xauthority: File exists
[DEBUG] [MOJO] launcher ERROR
[DEBUG] [MOJO] pinger STARTED
[DEBUG] [MOJO] resultHandler STARTED
[INFO] ------------------------------------------------------------------------
[INFO] Tests run: 0, Failures: 0, Errors: 0, Time Elapsed: 0 sec
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
I need help find out what is wrong. If any of you guys know any other way to run flex units test on linux, NOT THROUGH JENKINS/HUDSON, I will be extremely grateful.
First of all, just follow the linux part of the instructions on the following site:Running unit tests - FlexMojos. Download the flashplayer and untar it some appropriate place and put the absolute directory path in your PATH variable.
Download the xvfb-run script and change the following 'fi'
# If the user did not specify an X authorization file to use, set up a temporary
# directory to house one.
if [ -z "$AUTHFILE" ]; then
XVFB_RUN_TMPDIR="${TMPDIR:-/tmp}/$PROGNAME.$$"
if ! mkdir -p -m 700 "$XVFB_RUN_TMPDIR"; then
error "temporary directory $XVFB_RUN_TMPDIR already exists"
exit 4
fi
AUTHFILE=$(mktemp -p "$XVFB_RUN_TMPDIR" Xauthority)
fi
to
# If the user did not specify an X authorization file to use, set up a temporary
# directory to house one.
if [ -z "$AUTHFILE" ]; then
XVFB_RUN_TMPDIR=$(mktemp -d)
if ! mkdir -p -m 700 "$XVFB_RUN_TMPDIR"; then
error "temporary directory $XVFB_RUN_TMPDIR already exists"
exit 4
fi
AUTHFILE=$(mktemp "$XVFB_RUN_TMPDIR/Xauthority")
fi
I solved my problem, hopefully you will too.
Good luck.

Drush status: unrecoverable error caused by drupal_goto() in hook_init()

I have a module with a drupal_goto() that redirects users if they don't pass the age requirements (wine site) in hook_init(). The module is set with a heavier weight so it loads last.
On PHP 5.3, drush update fails. The same code and DB on a different server with PHP 5.2 runs fine.
Drush version: 7.x-4.4
PHP version: 5.3 example:
When I run: drush status, I get an error. Here is the output with the debug and verbose flag.
$ drush -d -v status
Bootstrap to phase 0. [0.02 sec, 2.47 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drush() [0.03 sec, 2.67 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_root() [0.06 sec, 5.49 MB] [bootstrap]
Initialized Drupal 6.22 root directory at /var/www/example.com/public_html [0.07 sec, 6.28 MB] [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [0.07 sec, 6.29 MB] [bootstrap]
Initialized Drupal site default at sites/default [0.07 sec, 6.29 MB] [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_configuration() [0.08 sec, 6.29 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_database() [0.08 sec, 6.33 MB] [bootstrap]
Successfully connected to the Drupal database. [0.08 sec, 6.33 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [0.09 sec, 6.67 MB] [bootstrap]
Drush command terminated abnormally due to an unrecoverable error. [0.34 sec, 31.38 MB] [error]
The question is now: Why does the drupal_goto() cause drush to fail on the PHP 5.3 server and not the PHP 5.2 server.
You should not issue redirects when there is an access denied. That is a logical error in any web-framework. You should issue an "access denied" when you want to deny access. Just like you issue a "the content has moved there, please go there" when your content has moved.
Instead of drupal_goto(), use drupal_access_denied(). If you truly want people to be redirected to another url, the place to do that, would be on the page that shows the denied access.
That said, issuing a drupal_access_denied(), or, in fact, sending any header in hook_init() is plain wrong. From the documentation: «Perform setup tasks.» Sending headers is not a setup-task. Moreover, that same documentation warns about another potential problem with your approach: «This hook is not run on cached pages», in other words, once an adult visits a page, and it is cached, underaged visitors will not be redirected or denied access, they will get the cached page served.
Now, on to what you should do:
A module such as Taxonomy Access (Lite) or the more appropriate Node Privacy By Role can be used to grant access to your content. Note that, by default, Views will not use these access: they will show lists of content, regardless of the access by the user: you will have to reconfigure all your views to either honor the access-rules or to be inaccassible entirely, to certain roles.
In addition, you need to give "minors" a separate role: that way you can grant them different access then the people in rol "authenticated user" or even in "adult". You will need some mechanism to automatically assign roles.

Resources