"#!" does not have special meaning for Web server SAPI.

I think you are sending data larger than output buffer size. Then this is the 
way supposed to be.

output_buffering=On or 1 is special. It enables unlimited buffering. Anything 
other values set buffer chunk size and PHP tries to send data larger than chunk 
size.

Check your buffer size (i.e. output_buffering setting of php.ini file)
I guess you have very small output_buffering. Old output buffer increases size 
automatically, IIRC. New output buffer does not increase buffer size.

I also tried the settings of On and 1.

I also understand that #!/usr/bin/php means nothing to output buffering but is output that 
I want to capture if the php file is being run from a browser and discard.

From what I understand that is not how the output buffering works. The way I understand it 
the output buffer fills then dumps everything when it is full. In this instance before the 
output buffer fills I want to discard the first 15 characters because it will corrupt any 
binary files that the browser is trying to download.


Based on the test script attached ob_get_length() should ALWAYS return 15 characters - 
however at least 12 times a day PHP fails to start the output buffer and I get the error 
shown.

Looks like when this is logged, there actually is no output buffer active, so 
ob_get_length() returns false.

@mike at php.net Yes that is the bug I'm reporting - the php.ini setting does not 
start the output buffer on every request.

I guess there is some kind of memory problem.
What modules are loaded in your web server and SAPI?

<?php
var_dump(get_loaded_extensions(), php_sapi_name());                                                               
?>

or paste phpinfo() output.

> at least 12 times a day PHP fails to start the output buffer and I get the 
error shown.

How many requests a day you have?

Extensions

  string(4) "Core"
  [1]=>
  string(4) "date"
  [2]=>
  string(4) "ereg"
  [3]=>
  string(6) "libxml"
  [4]=>
  string(7) "openssl"
  [5]=>
  string(4) "pcre"
  [6]=>
  string(4) "zlib"
  [7]=>
  string(3) "bz2"
  [8]=>
  string(8) "calendar"
  [9]=>
  string(5) "ctype"
  [10]=>
  string(4) "hash"
  [11]=>
  string(6) "filter"
  [12]=>
  string(3) "ftp"
  [13]=>
  string(7) "gettext"
  [14]=>
  string(3) "gmp"
  [15]=>
  string(3) "SPL"
  [16]=>
  string(5) "iconv"
  [17]=>
  string(10) "Reflection"
  [18]=>
  string(7) "session"
  [19]=>
  string(8) "standard"
  [20]=>
  string(5) "shmop"
  [21]=>
  string(9) "SimpleXML"
  [22]=>
  string(7) "sockets"
  [23]=>
  string(8) "mbstring"
  [24]=>
  string(9) "tokenizer"
  [25]=>
  string(3) "xml"
  [26]=>
  string(14) "apache2handler"
  [27]=>
  string(7) "gearman"
  [28]=>
  string(4) "http"
  [29]=>
  string(4) "ssh2"
  [30]=>
  string(4) "curl"
  [31]=>
  string(3) "dom"
  [32]=>
  string(8) "fileinfo"
  [33]=>
  string(2) "gd"
  [34]=>
  string(8) "igbinary"
  [35]=>
  string(4) "json"
  [36]=>
  string(4) "exif"
  [37]=>
  string(6) "mcrypt"
  [38]=>
  string(9) "memcached"
  [39]=>
  string(7) "mysqlnd"
  [40]=>
  string(5) "mysql"
  [41]=>
  string(6) "mysqli"
  [42]=>
  string(8) "newrelic"
  [43]=>
  string(3) "PDO"
  [44]=>
  string(9) "pdo_mysql"
  [45]=>
  string(10) "pdo_sqlite"
  [46]=>
  string(4) "Phar"
  [47]=>
  string(5) "posix"
  [48]=>
  string(4) "snmp"
  [49]=>
  string(4) "soap"
  [50]=>
  string(7) "sqlite3"
  [51]=>
  string(7) "sysvmsg"
  [52]=>
  string(7) "sysvsem"
  [53]=>
  string(7) "sysvshm"
  [54]=>
  string(4) "wddx"
  [55]=>
  string(9) "xmlreader"
  [56]=>
  string(9) "xmlwriter"
  [57]=>
  string(3) "xsl"
  [58]=>
  string(3) "zip"
  [59]=>
  string(5) "mhash"
  [60]=>
  string(12) "Zend OPcache"
}
string(14) "apache2handler"


12 requests where I was able to note that the output buffer failed out of 142 
requests to that specific script.

As a whole I average 150,000 PHP requests per day

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

This was resolved when the php agent from New Relic was updated the end of August.