as shown by upstream bug 499, when a fastcgi application writes to stderr the message gets printed in the terminal that was used to start lighttpd instead of the error log because lighttpd fails to close stderr before forking. writing directly to the error log of lighttpd from fastcgi violates the fastcgi specification but it is better than printing the messages to the terminal where lighttpd was started and sadly it seems that since mod_cgi connects stderr to the logs it is a common misconception/bug for mod_fastcgi applications to try to print to stderr and expect that magically to get to the web server log (only valid if using fcgi_stdio.h). Reproducible: Always Steps to Reproduce: 1. deploy lighttpd with fastcgi support 2. deploy an application using native fastcgi and printing to stderr (one provided below) 3. start lighttpd by running as a normal user (taking that port is not 80): /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf Actual Results: the messages that were printed to stderr show in your terminal session Expected Results: the messages that were printed to stderr shouldn't show at all or be printed in the error log (as a compatible with mod_cgi behavior) as shown by the following log excerpt: This is some error going to stderr 2007-01-28 14:08:02: (mod_fastcgi.c.2555) FastCGI-stderr: This is some error /* compile with: gcc -lfcgi */ #include "fcgi_config.h" #include "fcgiapp.h" #include <stdio.h> int main() { FCGX_Stream *in, *out, *err; FCGX_ParamArray envp; while (FCGX_Accept(&in, &out, &err, &envp) >= 0) { FCGX_FPrintF(out, "Content-type: text/html\r\n"); FCGX_FPrintF(out, "\r\n"); FCGX_FPrintF(out, "This is some content"); FCGX_FPrintF(err, "This is some error"); fprintf(stderr, "This is some error going to stderr\n"); } return 0; }
Created attachment 108428 [details, diff] patch for lighttpd 1.4.x's mod_fastcgi to link stderr for the fastcgi processes with the error log in gentoo's format this patch also includes support for having the errorlog be a pipe as implemented by gentoo patch 03. tested with a lighttpd-1.4.13-r1 based ebuild, and all it should need is to drop this patch in the files/1.4.13 directory.
Lighty is at 1.4.19 now. Has this been fixed upstream already?
upstream has rejected the issue - and we wont carry this patch infinitely. if this feature is really really wanted bug upstream some more. sorry and thanks Thilo
