Receiving MANY "Use of undefined constant STDERR" type errors running core-cron [#1064690]

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

jonhattan

Spanish

Plasencia

commented 17 February 2011 at 15:39

Status:

Active

» Postponed (maintainer needs more info)

See http://bugs.php.net/43283

How does your cron line looks like?

Comment #2

mdlueck commented 17 February 2011 at 16:20

Specifically the code that runs Drush...

echo $DATETIME drush core-cron cron.php begin | /usr/bin/tee -a $LOGFILE
/usr/bin/nice -n19 /usr/local/bin/php5 /kunden/homepages/35/d157794216/htdocs/drush4/drush.php --root=$1 --uri=http://$2 --debug --nocolor core-cron 2>&1 | /usr/bin/tee -a $LOGFILE

Comment #3

mdlueck commented 17 February 2011 at 19:42

Status:

Postponed (maintainer needs more info)

» Needs work

Status	File	Size
new	drush.inc_.diff	477 bytes

I 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 commented 19 February 2011 at 18:59

Status:

Needs work

» Postponed (maintainer needs more info)

#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 commented 20 February 2011 at 12:36

Please see my patch again. I was able to get rid of the STDERR messages by putting single quotes around STDERR.

drush_print($message, 0, '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 commented 20 February 2011 at 04:51

I'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 commented 20 February 2011 at 12:39

I 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 commented 20 February 2011 at 12:49

One 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 commented 21 February 2011 at 03:04

Based 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:

> which php5
/usr/local/bin/php5

/usr/local/bin > ls -al|grep php
lrwxrwxrwx  1 root root        4 Jun 17  2008 php -> php4
lrwxrwxrwx  1 root staff      20 Mar  7  2008 php-config -> ../../bin/php-config
lrwxrwxrwx  1 root staff      21 Mar  7  2008 php-config5 -> ../../bin/php-config5
lrwxrwxrwx  1 root staff      14 Mar  7  2008 php4 -> ../../bin/php4
lrwxrwxrwx  1 root staff      14 Mar  7  2008 php5 -> ../../bin/php5
lrwxrwxrwx  1 root staff      16 Mar  7  2008 phpize -> ../../bin/phpize
lrwxrwxrwx  1 root staff      17 Mar  7  2008 phpize5 -> ../../bin/phpize5

/usr/local/bin > php5 --version
PHP 5.2.17 (cgi) (built: Jan 11 2011 10:23:09)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies

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 commented 21 February 2011 at 03:14

Oh, 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 commented 24 February 2011 at 15:51

I received back the official answer from the hosting provider:

Unfortunately we are unable to install the php-cli on our shared hosting webservers. The business package you have is intended for web hosting, so only the cgi is installed. We do offer server accounts that you would have root access to, allowing you to install the cli yourself.

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 commented 24 February 2011 at 16:03

Status:

Postponed (maintainer needs more info)

» Closed (works as designed)

We publicize especially drush friendly web hosts at http://drush.ws/resources

Comment #13

mdlueck commented 24 February 2011 at 20:41

Status:

Closed (works as designed)

» Needs work

Not 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 commented 24 February 2011 at 20:54

Status:

Needs work

» Closed (works as designed)

Running drush on php-cgi has never been a supported configuration.

Comment #15

shahbaaz commented 14 September 2011 at 07:00

use 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 commented 21 September 2011 at 13:58

I 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 commented 17 October 2012 at 16:30

If 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 commented 30 November 2012 at 22:09

#17 solved "fwrite() expects parameter 1 to be resource, string given in . . ."

Thank you

Comment #19

fahey252 commented 24 December 2012 at 17:41

I 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 commented 25 December 2012 at 23:52

You 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 commented 8 May 2013 at 21:01

+1 fahey252 appears correct - #17 seems to work on 1and1 Linux hooray! Thank you leturan .

Comment #22

jazzitup commented 25 November 2013 at 11:25

I think this code/patch should be ported:

$sapi = PHP_SAPI;
if (strpos($sapi, 'cgi') !== false) {
  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 #23

greg.1.anderson commented 25 November 2013 at 17:17

Drush does not support php-cgi. See #20.

Comment #24

mdlueck commented 9 June 2017 at 10:01

The 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

/usr/bin$ ls -al | grep php
lrwxrwxrwx  4 root root             21 Feb 28 06:32 php -> ../lib/cgi-bin/php4.4
-rwxr-xr-x  8 root root           1030 Feb 28 06:32 php-config4.4
-rwxr-xr-x  8 root root           4405 Mar  1 02:50 php-config5.2
-rwxr-xr-x 12 root root           3905 Mar  1 04:15 php-config5.4
-rwxr-xr-x 12 root root           3895 Mar  1 05:05 php-config5.5
lrwxrwxrwx  4 root root             13 Mar  1 04:15 php-config6 -> php-config5.4
lrwxrwxrwx  4 root root              6 Feb 28 06:32 php4 -> php4.4
lrwxrwxrwx  4 root root             21 Feb 28 06:32 php4.4 -> ../lib/cgi-bin/php4.4
-rwxr-xr-x  8 root root        4502656 Feb 28 06:32 php4.4-cli
lrwxrwxrwx  4 root root              6 Mar  1 02:51 php5 -> php5.2
lrwxrwxrwx  4 root root             21 Mar  1 02:51 php5.2 -> ../lib/cgi-bin/php5.2
-rwxr-xr-x  8 root root        8307384 Mar  1 02:51 php5.2-cli
lrwxrwxrwx  4 root root             21 Mar  1 04:15 php5.4 -> ../lib/cgi-bin/php5.4
-rwxr-xr-x 12 root root       12662384 Mar  1 04:15 php5.4-cli
lrwxrwxrwx  4 root root             21 Mar  1 05:05 php5.5 -> ../lib/cgi-bin/php5.5
-rwxr-xr-x 12 root root       13201840 Mar  1 05:05 php5.5-cli
lrwxrwxrwx  4 root root             21 Mar  1 04:15 php6 -> ../lib/cgi-bin/php5.4
-rwxr-xr-x  8 root root           3989 Feb 28 06:32 phpize4.4
-rwxr-xr-x  8 root root           4481 Mar  1 02:51 phpize5.2
-rwxr-xr-x 12 root root           4495 Mar  1 04:15 phpize5.4
-rwxr-xr-x 12 root root           4495 Mar  1 05:05 phpize5.5
lrwxrwxrwx  4 root root              9 Mar  1 04:15 phpize6 -> phpize5.4
lrwxrwxrwx  4 root root             26 Dec  7  2016 wp -> ../share/php/wp-cli/bin/wp

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!

$ /usr/bin/php5.5-cli /kunden/homepages/35/d157794216/htdocs/bin/drush.phar help
Execute a drush command. Run `drush help [command]` to view command-specific help.  Run `drush topic` to read even more documentation.

Global options (see `drush topic core-global-options` for the full list):
 -d, --debug                               Display even more information, including internal messages.                                                 
 -h, --help                                This help system.                                                                                           
 -n, --no                                  Assume 'no' as answer to all prompts.                                                                       
 -r <path>, --root=<path>                  Drupal root directory to use (default: current directory).                                                  
 -s, --simulate                            Simulate all relevant actions (don't actually change the system).                                           
 -l <http://example.com:8888>,             URI of the drupal site to use (only needed in multisite environments or when running on an alternate port). 
 --uri=<http://example.com:8888>                                                                                                                       
 -v, --verbose                             Display extra information about the command.                                                                
 -y, --yes                                 Assume 'yes' as answer to all prompts.

Core Drush commands: (core)

etc...

Bing bing bing bing!

8) I recommend running Drupal cron via Drush executed with the nice command:

~/bin$ cat drupal-cron.php.sh 
#!/bin/bash -x
#/************************************************************************************/
#/*                      Lueck Data Systems - Managed Web Hosting                    */
#/* FILENAME       :  drupal-cron.php.sh                                             */
#/* TYPE           :  Bash                                                           */
#/* DESCRIPTION    :  This script receives arguments from site specific scripts, then*/
#/*                   submits them to drush for actual execution of Drupal's cron    */
#/*                                                                                  */
#/* AUTHOR         :  Michael D Lueck                                                */
#/*                   mlueck@lueckdatasystems.com                                    */
#/*                                                                                  */
#/* NEEDS          :                                                                 */
#/*                                                                                  */
#/* USAGE          :  PathToWebRoot                                                  *
#/*                   DomainName                                                     */
#/*                                                                                  */
#/* RETURNS        :                                                                 */
#/*                                                                                  */
#/* REVISION HISTORY                                                                 */
#/*                                                                                  */
#/* DATE       REVISED BY DESCRIPTION OF CHANGE                                      */
#/* ---------- ---------- -------------------------------------------------------    */
#/* 2014/05/15 MDL        Initial Creation                                           */
#/* 2014/07/19 MDL        Restored 132 column mode                                   */
#/* 2017/06/08 MDL        Updated to make work with Drush v8.x and the *.phar build, */
#/*                       Specify TEMP directory via environment variable            */
#/************************************************************************************/

DATE=`/bin/date +%Y%m%d`
DATETIME=`/bin/date +%Y%m%d-%H%M%S`
LOGFILE=/kunden/homepages/35/d157794216/htdocs/reports/$DATE.${2}.drupal8-cron.php.sh.log
export COLUMNS=132
export TEMP=/kunden/homepages/35/d157794216/htdocs/var/tmp

echo $DATETIME drush core-cron cron.php begin | /usr/bin/tee -a $LOGFILE
/usr/bin/nice -n19 /usr/bin/php5.5-cli /kunden/homepages/35/d157794216/htdocs/bin/drush.phar --root=$1 --uri=http://$2 --debug --nocolor core-cron 2>&1 | /usr/bin/tee -a $LOGFILE

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.

Receiving MANY "Use of undefined constant STDERR" type errors running core-cron

Comments

Comment #1

Comment #2

Comment #3

Comment #4

Comment #5

Comment #6

Comment #7

Comment #8

Comment #9

Comment #10

Comment #11

Comment #12

Comment #13

Comment #14

Comment #15

Comment #16

Comment #17

Comment #18

Comment #19

Comment #20

Comment #21

Comment #22

Comment #23

Comment #24

News items

Our community

Documentation

Drupal code base

Governance of community