Closed (fixed)
Project:
Drush
Version:
7.x-4.4
Component:
Core Commands
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
26 May 2011 at 00:38 UTC
Updated:
17 Feb 2012 at 22:30 UTC
I am in the process of applying the Drupal Cor security update and that breaks Drush's ability to run core-cron.
Attached is a zip file with three text file logged run outputs. I am actually running drush-6.x-3.3.tar.gz currently for D6 sites. I also tried drush-All-versions-4.2.tar.gz which also fails to run with D6.22 applied.
So, last good run while at D6.20, and two error reports, one with Drush 3 and one with Drush 4.
| Comment | File | Size | Author |
|---|---|---|---|
| drush_cron_error.zip | 2.36 KB | mdlueck |
Comments
Comment #1
Methos76 commented[posted here by error, sorry]
Comment #2
mdlueck commentedAn update, I found this bug report:
"Drush unable to update to 6.22"
http://drupal.org/node/1169776
I upgraded to the stable release of drush-7.x-4.4.tar.gz and running core-cron still exhibits the same errors I had reported here before. So no change.
Comment #3
mdlueck commentedComment #4
greg.1.anderson commentedcore-cron works fine for me in drush-5.x master after upgrading to Drupal 6.22.
Comment #5
mdlueck commentedVery well, I pulled down: All-versions-5.x-dev drush-All-Versions-HEAD.tar.gz 2011-Feb-03
And yet receive errors trying to run cron:
I only applied my diff to Drush from here:
"Receiving MANY "Use of undefined constant STDERR" type errors running core-cron"
http://drupal.org/node/1064690
Comment #6
greg.1.anderson commentedAs noted in the issue you quoted, you are running drush in an unsupported configuration. If core-cron worked in this configuration in 6.20, that was just a coincidence. You must run drush with php-cli, not php-cgi.
Comment #7
mdlueck commentedI tested Drush also on a server with the following specs:
Ubuntu 8.04
Apache with mod_php
php-cli
The error messages running Drush before / after the 6.20 --> 6.22 are IDENTICAL to the error messages I was getting from the server which runs php as a cgi.
Therefor it is NOT because php is run as a cgi on the one server.
Someone suggested to check the Drupal file permissions. All perms are correct.
Someone suggested running drush as root. I sudo'ed the shell script which runs drush / Drupal cron, and received the same error messages.
Seems like something in the 6.22 upgrade broke drush. I am very surprised more people are not slamming into this.
Might it be due to my running with verbose drush output?
Trouble seems to start when it reaches point:
session_start() [function.session-start]: Cannot send session cookie - headers [warning]
So what is drush trying to do at this point?
Comment #8
greg.1.anderson commentedWorks for me with Drupal 6.22 and -v. Try disabling all modules; if that works, then try to isolate the module that is causing the problem.
Comment #9
jonhattanPerhaps a module doing a redirect in hook_init(), as @bkosborne recently identified here: http://drupal.org/node/1140842#comment-4526230
try disabling the modules of the list obtained with
drush php-eval "print_r(module_implements('init'));"Comment #10
mdlueck commented@greg.1.anderson: It will be a few days until I can have a copy of the site which to disable all of the modules on.
@jonhattan: Thank you for the suggestion. Still banging into issues:
Comment #11
greg.1.anderson commented(deleted) Said the wrong thing; need to check my notes and put in the right solution.
Comment #12
greg.1.anderson commentedComment #13
greg.1.anderson commentedTry the patch at #1174496: WSOD: drupal_error_handler() assumes filter_xss() is defined and see if that helps.
Comment #14
mdlueck commentedI disabled all of the mods (other than core) this evening on a test subdomain. Error still persists.
I just saw a post at CiviCRM complaining of the same thing with Drupal 6.22, and the suggestion was to drop back to 6.20. It seems to me that the features they tried to give us have a bug someplace.
Look at all of the posts racked up...
http://www.google.com/search?client=firefox-a&rls=org.mozilla%3Aen-US%3A...
Comment #15
bdone commentedjust confirming that patch mentioned in #13 clears up some drush errors. see: http://drupal.org/node/1174496#comment-4843330
drush version 4.4
d6 6.22
Comment #16
jonhattanWe recently get rid of drupal_error_handler at #1204862: drush up can't update D7 because of drupal error handler intervention. so it shouldn't be an issue now. Please confirm.
Comment #17
bdone commentednot sure that i can confirm, if comment #16 was intended for me. i wasn't upgrading to d7, nor was i using drush up.
but, i was receiving an error in drush output, when running the following command:
drush sql-sync @mysite.staging @mysite.localhost -y --no-cache --sanitizein my setup, that error didn't begin occurring until a recent core upgrade from 6.x to 6.22.
the following patch removed the error: http://drupal.org/node/1174496#comment-4629384
Comment #18
mdlueck commentedIndeed: http://drupal.org/node/1174496#comment-4629384 resolved this error for us.
I think this issue may safely be closed now.
Comment #19
greg.1.anderson commentedMarking as 'reviewed & tested', but leaving open until above core patch is committed in Drupal.
Comment #20
brunorios1 commentedsubscribing
Comment #21
greg.1.anderson commented#1174496: WSOD: drupal_error_handler() assumes filter_xss() is defined has been committed, and should be part of Drupal 6.23 when it is released in early February. Marking this as 'fixed'.
Comment #22
mdlueck commentedConfirmed: Just finished up applying D6.24 on all sites. Works successfully with Drush on both php-cli and php-cgi.