Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Using scripts we developed to use Drush to run Drupal's cron for D6, we are getting much NOISE in the logs now with D7 / Drush 4. Example as follows:
<b>Notice</b>: Use of undefined constant STDERR - assumed 'STDERR' in <b>/homepages/35/d157794216/htdocs/drush4/includes/drush.inc</b> on line <b>2310</b><br />
<br />
<b>Warning</b>: fwrite(): supplied argument is not a valid stream resource in <b>/homepages/35/d157794216/htdocs/drush4/includes/drush.inc</b> on line <b>577</b><br />
<br />
<b>Notice</b>: Use of undefined constant STDERR - assumed 'STDERR' in <b>/homepages/35/d157794216/htdocs/drush4/includes/drush.inc</b> on line <b>2310</b><br />
<br />
<b>Warning</b>: fwrite(): supplied argument is not a valid stream resource in <b>/homepages/35/d157794216/htdocs/drush4/includes/drush.inc</b> on line <b>577</b><br />
<br />
<b>Notice</b>: Use of undefined constant STDERR - assumed 'STDERR' in <b>/homepages/35/d157794216/htdocs/drush4/includes/drush.inc</b> on line <b>2310</b><br />
<br />
<b>Warning</b>: fwrite(): supplied argument is not a valid stream resource in <b>/homepages/35/d157794216/htdocs/drush4/includes/drush.inc</b> on line <b>577</b><br />
Timer Cum (sec) Count Avg (msec)
page 7.546 1 7546.14
<br />
<b>Notice</b>: Use of undefined constant STDERR - assumed 'STDERR' in <b>/homepages/35/d157794216/htdocs/drush4/includes/drush.inc</b> on line <b>2310</b><br />
<br />
<b>Warning</b>: fwrite(): supplied argument is not a valid stream resource in <b>/homepages/35/d157794216/htdocs/drush4/includes/drush.inc</b> on line <b>577</b><br />
Our scripts capture both STDOUT and STRERR output combined and maintain a daily running log for each site. We were accustomed to seeing Drush produce clean and yet verbose/detailed logs of what cron did while it was operating. Not HTML formatted, and not with these countless error warnings.
Did Drush somehow change in the D7 version and we must now change how we are script driving it, or is this truly a new bug?
Comment | File | Size | Author |
---|---|---|---|
#3 | drush.inc_.diff | 477 bytes | mdlueck |
Comments
Comment #1
jonhattanSee http://bugs.php.net/43283
How does your cron line looks like?
Comment #2
mdlueck CreditAttribution: mdlueck commentedSpecifically the code that runs Drush...
Comment #3
mdlueck CreditAttribution: mdlueck commentedI at least hacked the code enough to arrive at the results we were expecting. Please find the patch attached and release the appropriate new version.
Comment #4
greg.1.anderson CreditAttribution: greg.1.anderson commented#3 is unacceptable; it is in conflict with #639204: drush_log() should write to stderr, not stdout, and $green should actually be green..
The first thing you need to do is find out why STDERR is not recognized as a valid constant on your system. It should always be. See:
http://php.net/manual/en/wrappers.php.php
You already have
2>&1
on the end of your cron line, so you will see both stderr and stdout on the standard output stream once this works.Comment #5
mdlueck CreditAttribution: mdlueck commentedPlease see my patch again. I was able to get rid of the STDERR messages by putting single quotes around STDERR.
That left the other error remaining, however. The "fwrite(): supplied argument is not a valid stream resource in" one... So I handed it back to you to sort out the proper way to write to STDERR.
And I did try removing the 2>&1 and that fwrite() error yet persisted, so that is when I hack removed the reference to STDERR, simply to get success for the time being. Thus my comment of the patch as "hacked the code".
The server runs Debian 4.0, and the PHP level is currently "PHP 5.2.17 (cgi) (built: Jan 11 2011 10:23:09)" running as CGI.
Yes I had come across that PHP page covering PHP I/O trying to figure out what might be wrong with Drush. Could you please provide a simple example script I might run to test what is going on? Thank you!
Comment #6
greg.1.anderson CreditAttribution: greg.1.anderson commentedI'm afraid you are confused. Putting single quotes around STDERR is not what you did in #3; that particular line is commented out. And it is no wonder that doing that gave you "fwrite(): supplied argument is not a valid stream resource", because 'STDERR' is a string; that change is not at all appropriate. STDERR is a stream resource, which is what is needed for fwrite. It should always be defined. Since I have no idea why it wouldn't be defined, you are going to have to keep working on this yourself. This code has always worked for me.
Comment #7
mdlueck CreditAttribution: mdlueck commentedI commented that line out when the "fwrite()" errors yet persisted once I had added the quotes.
Very well, then I will post to the hosting provider for further assistance. Perhaps they will know why STDERR is not a valid I/O device.
Thank you.
Comment #8
Damien Tournoud CreditAttribution: Damien Tournoud commentedOne likely reason is that your hosting provider is making the PHP CGI binary available on the command line instead of the PHP CLI one.
Comment #9
mdlueck CreditAttribution: mdlueck commentedBased on #8, I went searching and quickly came across this:
http://www.php-cli.com/php-cli-cgi.shtml
Details seem to be Windows centric and not Linux specific. So here are the binaries I see on the server:
What would the PHP-CLI Linux executable be named, if not php5? Perhaps it too is installed, and I just do not know its proper name.
Comment #10
mdlueck CreditAttribution: mdlueck commentedOh, judging from peeking into the Ubuntu package documentation, looks like only the CGI might be installed on this Debian server.
Oddly the name of the binary in Ubuntu for CLI is php5, whereas the CGI binary is php5-cgi. So I am thinking that it might not be possible for the hosting provider to simply add the PHP5-CLI package... but perhaps they have a technique to arrive at the needed configuration.
Comment #11
mdlueck CreditAttribution: mdlueck commentedI received back the official answer from the hosting provider:
So I guess I will need to operate with customized Drush for now.
Please consider adding a switch to send output to a device which does exist in php-cgi mode.
Comment #12
moshe weitzman CreditAttribution: moshe weitzman commentedWe publicize especially drush friendly web hosts at http://drush.ws/resources
Comment #13
mdlueck CreditAttribution: mdlueck commentedNot an issue for Drush 3.x for Drupal 6, should not be a new issue with Drush 4.x for Drupal 7 then. Drush changed, requiring code adjustment to have it work on the same server which Drush for Drupal 6 works fine on, so I request you soften that minor sharp spot and prevent code customization.
Comment #14
greg.1.anderson CreditAttribution: greg.1.anderson commentedRunning drush on php-cgi has never been a supported configuration.
Comment #15
shahbaaz CreditAttribution: shahbaaz commenteduse this command to know exact location of php5 before installing:
which php5
Then follow these instructions: http://knol.google.com/k/how-to-install-drupal-with-drush#
This solved my problem.
Comment #16
Agence Web CoherActio CreditAttribution: Agence Web CoherActio commentedI am having the same problem as mdlueck.
The fix in #3 works. At the moment download and install works fine.
What are the side effects if any ?
Thanks
Comment #17
leturan CreditAttribution: leturan commentedIf u'r using CGI instead of CLI 'cause like me, u can put those lines under in the first lines of the file drush.php in ur drush install repository. :
if (!defined('STDIN'))
{
define('STDIN', fopen('php://stdin', 'r'));
}
if (!defined('STDOUT'))
{
define('STDOUT', fopen('php://stdout', 'w'));
}
if (!defined('STDERR'))
{
define('STDERR', fopen('php://stderr', 'w'));
}
Comment #18
dana.elza CreditAttribution: dana.elza commented#17 solved "fwrite() expects parameter 1 to be resource, string given in . . ."
Thank you
Comment #19
fahey252 CreditAttribution: fahey252 commentedI am using 1and1 Linux hosting on a shared server. Encountered this problem too. Don't like adding lines to drush.php due to overwriting on upgrade, but #17 worked for me!
Comment #20
greg.1.anderson CreditAttribution: greg.1.anderson commentedYou could try putting the lines from #17 in the init method of your own Drush extension. For example, if you had a module in a commandfile named unsupported_configuration.module in your ~/.drush folder, then you would make a method called
function unsupported_configuration_init()
, and fill in its body as described above. You'd still get the error messages for anything that Drush tried to print before it ran your init function, but I'd guess that it usually wouldn't print anything that early in the process. Worth a try, anyway.Comment #21
HongPong CreditAttribution: HongPong commented+1 fahey252 appears correct - #17 seems to work on 1and1 Linux hooray! Thank you leturan .
Comment #22
jazzitup CreditAttribution: jazzitup commentedI think this code/patch should be ported:
Comment #23
greg.1.anderson CreditAttribution: greg.1.anderson commentedDrush does not support php-cgi. See #20.
Comment #24
mdlueck CreditAttribution: mdlueck commentedThe need for this Drush modification when running on 1&1 Shared Linux Web Hosting packages has been resolved. 1&1 installs on their Debian based servers php-cli, just at a different path. Now my recommendations are as follows:
1) Download drush.phar from https://github.com/drush-ops/drush/releases (Example: version 8.1.12)
2) Make directory in home directory of 1&1 Shared Linux Web Hosting package:
~$ mkdir drush
3) Upload renamed drush.phar file as: drush_8.1.12.phar inserting the downloaded version number into the resulting filename.
4) Make another directory in home directory of 1&1 Shared Linux Web Hosting package:
~$ mkdir bin
5) In that bin directory, create symlink to the current version of the drush.phar file:
~/bin$ ln -s ../drush/drush_8.1.12.phar drush.phar
6) Locate the latest desirable version of the php-cli binary to use to execute drush.phar
php5.5-cli is the highest version of php-cli pre-installed by 1&1 which is compatible with Drush 8.x releases, so we will select that version to utilize.
7) Time to test it out!
etc...
Bing bing bing bing!
8) I recommend running Drupal cron via Drush executed with the nice command:
Note: This implementation method makes use of placing date prefixed log files into a directory off the home directory of ~/reports. It is implied to run some sort of FIFO log cleanup. We use another shell script run via crontab to purge old logfiles. Also, ~/var/tmp directory is needed as Drush makes use of tmp files. Drush seems to clean up after itself as no tmp files it created remain in the TEMP directory once execution completes.
9) When newer versions of Drush are released you may try out newer versions uploading them into the ~/drush directory, using the same naming standard of placing the version number into the filename. Once success has been verified using the higher version of Drush, then simply update the symlink in step 5 above to switch your hosting package over to using the newer version. If issues are later found, simply switch the symlink back to point to the prior properly working version.