I confirm this deficiency: php5-fpm 5.3.9+ prevents fpm passing error_log output  
to the web server's error log via SAPI. 

I encounter this issue using nginx 1.0.11, but it is also present with older 
nginx releases. The problem is encountered even with 777 permissions on the 
logs. If I roll back to php5-fpm_5.3.8 (keeping the same configs), it starts 
working again. I would like fpm STDERR to output to the virtual host's error log 
(this was the default behavior before).

A sample php.ini/php-fpm.conf is attached:

/etc/php5/fpm/php.ini

[PHP]
engine = On
short_open_tag = Off
asp_tags = Off
precision = 14
y2k_compliance = On
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = 17
allow_call_time_pass_reference = Off
safe_mode = Off
safe_mode_gid = Off
safe_mode_include_dir =
safe_mode_exec_dir =
safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH
disable_functions =
disable_classes =
expose_php = On
max_execution_time = 30
max_input_time = 60
memory_limit = 128M
error_reporting = E_ALL & ~E_DEPRECATED
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
track_errors = Off
html_errors = Off
variables_order = "GPCS"
request_order = "GP"
register_globals = Off
register_long_arrays = Off
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 8M
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
doc_root =
user_dir =
enable_dl = Off
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 20
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60


/etc/php5/fpm/php-fpm.conf:

[global]
pid = /var/run/php5-fpm.pid
error_log = /var/log/php5-fpm.log
[www]
listen = /tmp/fcgi.socket
user = www-data
group = www-data
pm = dynamic
pm.max_children = 50
pm.start_servers = 25
pm.min_spare_servers = 5
pm.max_spare_servers = 35
pm.max_requests = 500
pm.status_path = /status
ping.path = /ping
ping.response = Ok
slowlog = log/$pool.log.slow
chdir = /

Add patch for 5.3.10.

It simple, not so right, because I think this functionality need move to zlog_ex, 
but it works for me.

If anybody can review it and test, would be nice.

confirmed on php v5.3.10

in fact, set display_errors to On, we can still view the error message, but the message didn't go to nginx error log when display_errors is set to Off.
test confirmed that the same setting works fine on php 5.3.8

"Me too", on FreeBSD 7.3 with nginx-1.0.14,1 and php5-5.3.10.

Exact same problem on Centos 6.2 with a custom build PHP 5.3.10. I reverted back to 5.3.8 since I need to have PHP errors in the Nginx error.log.

Same here on 5.3.9 and .10 on apache. Errors used to go to apache error log, but 
after 5.3.9 nothing gets logged.

I wonder if the change is actually by design, according to the php-fpm 
documentation for "catch_workers_output" is states that "If not set, stdout and 
stderr will be redirected to /dev/null according to FastCGI specs."

But it would definitely be great with and option to throw errors to stderr again.

I wouldn't mind that change, but setting "catch_workers_output = yes" doesn't work for me with PHP 5.3.10 and Nginx 1.0.14 on Centos 6.2.

The same here, I tried every php.ini and php-fpm.conf log setups, nothing works 
with Nginx 1.0.11 + PHP 5.3.10 FastCGI, even setting catch_workers_output = yes 
does not 
work.
I dont know why this functionality was cutted out but our sites use logging via 
stderr + nginx, please solve it.

Tracked the change through git/svn.

There is a zlog facility in php-fpm which provides output of operational errors, 
while fastcgi error logging facility is used to output application level errors.

You can see how merging those into a single zlog which works on both seems like 
a good idea, but currently zlog does not even know what fpm is, having no access 
to fpm/fcgi variables or functions.

So then, a patch "generalized" the behavior, and now all logs go through zlog.
Unfortunately, zlog has no means of transporting the errors through fastcgi 
interface, and so fastcgi logging was lost.

This is the patch in question: http://git.php.net/?p=php-
src.git;a=commitdiff;h=7fc36a5210e3066ad9b1ddff2e142e7a971ae1e9

The solution is either to revert this patch, or, which was probably the goal of 
the patch submitter, complete the zlog facility so it supports FastCGI natively.

Since it doesn't seem like anyone fixed the zlog facility for half a year (since 
October 2011), it does seem simpler to revert the patch, or at least set it up 
as an option...

The link to the patch got mangled:
http://git.php.net/?p=php-
src.git;a=commitdiff;h=7fc36a5210e3066ad9b1ddff2e142e7a971ae1e9

http://goo.gl/11Whb

This is a showstopper for us; we've had to revert back to 5.3.8 so that we can 
trace and debug our application in both production and development.

I've released 2 patches (for 5.3 and 5.4) .

Can you please test them and validate them on your side so that I can push them 
?

I've enhanced the zlog sublibrary to add the possibility to set an "external 
logger". In our case, the new function sapi_cgi_log_fastcgi() in fpm_main.c will 
send any messages (PHP and FPM) back to the fastcgi client no matter what the 
debug level is.

thx

I applied the patch against 5.3.12, and it appears to be working.

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Does this mean the fix will go live in the official 5.3.14 release?

Any news about when this will see a release? Maybe 5.3.15 ? 5.4.5?

yes this fix will go live in the next 5.3 and 5.4 release.

Is there a work around for us that are stuck on 5.3.10?

you can patch that patch your self.. if you really want to insist to 5.3.10

For those of you on Ubuntu Precise and wanting this bug to be fixed in an update,  
please subscribe to this bug in Launchpad and click "This bug affects me".  This 
will raise the Bug Heat score giving the bug more attention.

https://bugs.launchpad.net/ubuntu/+source/php5/+bug/999969