Lighttpd

Can confirm the same bug on OpenBSD running lighttpd-1.4.11.

Last conditional gets the error logging, access logging appears to be working correctly.

-- anil

Also on FreeBSD 6.1 running lighttpd-1.4.11 (ssl)

-- lighttpd

Also on Debian sarge running lighttpd 1.4.12

-- dp

can confirm it for lighttpd-1.4.13 on Debian-Sarge too

you know. your assumption is wrong. this is by design atm. this is only an enhancement request to make it conditional in the future.

just as a reminder.

It took me an hour to find this ticket. Many of the Wiki examples pretend that the error file is to be set individually for each vhost.

Example: http://trac.lighttpd.net/trac/wiki/HowToSetupFastCgiIndividualPermissions

-- alex

This bug is annoying if you try to do vhosting different customers.
Errors in their code should be going to their logfile.

-- Jan Scholten

Also on Fedora 7 running lighttpd 1.4.16.

-- Aleksey Klimov

Also on lighttpd 1.4.18

''"Bug opened 2 years_ ago."'' Oops!
Yep, virtual hosting needs this.

-- grin

Centos5
lighttpd-1.4.18 (ssl)

Still the same problem.
It might even be affecting php-cgi when misconfigured in this way. I was having issues of pages not loading. Browser would connect to the server but nothing would load. If you refreshed a couple of times it would eventually load. Sometimes there would be stuck php-cgi processes that I had to kill manually.

After trying to debug some scripts I found that all my 3-4 sites were logging to the same file as described here. Once I removed the lines in the conditionals, everything started working OK. Not sure if it was a coincidence or not.

If that was relating to the issue, it could be a bit bigger than we think, due to a lot of documentation on the web explaining that this is the way to do it.

-- ShaunO

This is not a bug - it just is.

As it is by design, i don't think this will ever get implemented.

You can start you fastcgi backends with custom scripts to pipe their errors into separate logs, so your customers can see their php errors.

And imho, server errors should be in a server-log, not in a vhost (and many errors may not even get to the point where the vhost is known).

Fixed the linked documentation.

We may work around this limitation by messing with the fastcgi script outputs, but this is not the point.

Virtual hosts should be as independent of each other as possible. Each can have their own access log. Why not their own error log? Apache does this. Is it impossible for lighttpd to do it as well?

Here are some arguments for separating error logs per vhost:

1. Virtual hosts are conceptually separated. This should be translated systematically and consistently into log separation. acceslog.filename is per vhost, so should be the errorlog.

2. One server admin may administer multiple web sites served by one lighty, the classic example being a 'stage' version of a site, and a 'prod' version. The same admin will want to treat the 'prod' errors with higher priority than the 'stage' errors, hence the need for separating them.

Please vote in this poll on whether lighttpd should separate error logs per virtual host, just like the access log, vs. amalgamating all errors into one server.errorlog.

I'm watching this issue and the e-mail notification about change #20 contained the following text:

One more stupid guy i don't care about.

What was that about, stbuehler?

This is unrelated to an actual fix in lighttpd but it may help some people until the fix appears.

A limited workaround for PHP is to early in your code do:

ini_set("error_log", "/path/to/your/own/error.log");

The file needs to be writeable by lighttpd of course (and dont forget to add it for log rotation if appropriate).

mk wrote:

This is unrelated to an actual fix in lighttpd but it may help some people until the fix appears.

A limited workaround for PHP is to early in your code do:

ini_set("error_log", "/path/to/your/own/error.log");

The file needs to be writeable by lighttpd of course (and dont forget to add it for log rotation if appropriate).

And what to do for those people who uses something different from PHP as a FastCGI backend?

Then those backends should provide a similar option; instead of looping the error message over a www-data user into log files you need to make available to the user again, just let the user log them.