Drush in ddev returns BadRequestHttpException - drupal

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.

Related

Stopping site <site-name> because it failed during startup

I'm currently trying to setup Bitnami's Wordpress + Nginx Docker with Azure App Service for Containers and I am stuck at the error message: Stopping site because it failed during startup.
I already tried to increase WEBSITES_CONTAINER_START_TIME_LIMIT without success. I also tried to find anything in the other logs, however, there is not relevant information.
This is my log:
2021-03-26T20:26:39.850Z INFO - Starting multi-container app..
2021-03-26T20:26:40.686Z INFO - Pulling image from Docker hub: registry.hub.docker.com/bitnami/wordpress-nginx
2021-03-26T20:26:42.009Z INFO - latest Pulling from bitnami/wordpress-nginx
2021-03-26T20:26:42.011Z INFO - Digest: sha256:08ea17712bc6cd31a20128557aa5bbad562dc81af2e9a26b4f45bfca40e5538c
2021-03-26T20:26:42.013Z INFO - Status: Image is up to date for registry.hub.docker.com/bitnami/wordpress-nginx:latest
2021-03-26T20:26:42.021Z INFO - Pull Image successful, Time taken: 0 Minutes and 1 Seconds
2021-03-26T20:26:42.050Z INFO - Starting container for site
2021-03-26T20:26:42.052Z INFO - docker run -d -p 9180:80 --name as-wp-weu-prod_wordpress_0_f1793421 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=true -e WEBSITE_SITE_NAME=as-wp-weu-prod -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=as-wp-weu-prod.azurewebsites.net -e WEBSITE_INSTANCE_ID=8d9749e1ad54987267d51cda41194309f78e9fe336b09f44ea04d81342bdd40c -e HTTP_LOGGING_ENABLED=1 registry.hub.docker.com/bitnami/wordpress-nginx
2021-03-26T20:56:42.520Z ERROR - multi-container unit was not started successfully
2021-03-26T20:56:42.546Z INFO - Container logs from as-wp-weu-prod_wordpress_0_f1793421 = 2021-03-26T20:26:49.138042862Z [0m
2021-03-26T20:26:49.138217863Z [0m[1mWelcome to the Bitnami wordpress-nginx container[0m
2021-03-26T20:26:49.138376864Z [0mSubscribe to project updates by watching [1mhttps://github.com/bitnami/bitnami-docker-wordpress-nginx[0m
2021-03-26T20:26:49.138532065Z [0mSubmit issues and feature requests at [1mhttps://github.com/bitnami/bitnami-docker-wordpress-nginx/issues[0m
2021-03-26T20:26:49.147750834Z [0m
2021-03-26T20:26:56.839294655Z nami INFO Initializing php
2021-03-26T20:26:56.907101461Z nami INFO php successfully initialized
2021-03-26T20:27:04.576803980Z nami INFO Initializing nginx
2021-03-26T20:27:04.676840017Z nami INFO nginx successfully initialized
2021-03-26T20:27:12.622656961Z nami INFO Initializing mysql-client
2021-03-26T20:27:12.721293503Z nami INFO mysql-client successfully initialized
2021-03-26T20:27:22.196788004Z nami INFO Initializing wordpress
2021-03-26T20:27:22.519271584Z wordpre INFO ==> Preparing Varnish environment
2021-03-26T20:27:22.527241945Z wordpre INFO ==> Preparing Apache environment
2021-03-26T20:27:22.537316623Z wordpre INFO ==> Preparing PHP environment
2021-03-26T20:27:22.588082613Z wordpre INFO WordPress has been already initialized, restoring...
2021-03-26T20:27:24.832051104Z mysql-c INFO Trying to connect to MySQL server
2021-03-26T20:27:24.861626532Z mysql-c INFO Found MySQL server listening at mariadb-weu-prod.mariadb.database.azure.com:3306
2021-03-26T20:27:25.130808807Z mysql-c INFO MySQL server listening and working at mariadb-weu-prod.mariadb.database.azure.com:3306
2021-03-26T20:27:25.130828007Z wordpre INFO Upgrading WordPress Database ...
2021-03-26T20:27:27.133719647Z wordpre INFO
2021-03-26T20:27:27.134393052Z wordpre INFO ########################################################################
2021-03-26T20:27:27.135004057Z wordpre INFO Installation parameters for wordpress:
2021-03-26T20:27:27.141716808Z wordpre INFO Persisted data and properties have been restored.
2021-03-26T20:27:27.142344313Z wordpre INFO Any input specified will not take effect.
2021-03-26T20:27:27.142926818Z wordpre INFO This installation requires no credentials.
2021-03-26T20:27:27.143452822Z wordpre INFO ########################################################################
2021-03-26T20:27:27.143975626Z wordpre INFO
2021-03-26T20:27:27.144505830Z nami INFO wordpress successfully initialized
2021-03-26T20:27:27.205315299Z [0m[38;5;2mINFO [0m ==> Starting gosu...
2021-03-26T20:27:27.243704595Z [0m[38;5;2mINFO [0m ==> Starting PHP-FPM...
2021-03-26T20:27:27.245663910Z [0m[38;5;2mINFO [0m ==> Starting NGINX...
2021-03-26T20:27:27.335050999Z 2021/03/26 20:27:27 [warn] 83#83: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /opt/bitnami/nginx/conf/nginx.conf:2
2021-03-26T20:27:27.335712104Z nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /opt/bitnami/nginx/conf/nginx.conf:2
2021-03-26T20:56:46.234Z INFO - Stopping site as-wp-weu-prod because it failed during startup
This is my docker-compose:
version: '3.9'
services:
wordpress:
image: registry.hub.docker.com/bitnami/wordpress-nginx
restart: always
ports:
- '8080:80'
volumes:
- ${WEBAPP_STORAGE_HOME}/site/wwwroot:/bitnami/wordpress
- ${WEBAPP_STORAGE_HOME}/site/server_blocks:/opt/bitnami/nginx/conf/server_blocks/wordpress-server-block.conf
Thank you!

drush up drupal fails on _drush_recursive_copy

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.

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

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