Feature #665

server.errorlog is global instead of per virtual host

Added by Anonymous over 8 years ago. Updated 5 days ago.

Status:InvalidStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:core
Target version:1.5.0
Missing in 1.5.x:No

Description

when defining a server.errorlog in some conditionals, the last server.errorlog instruction is taken has global :

server.errorlog = "/home/foo/logs/error.log"

$HTTPhost =~ "first.foo.com$" {
server.document-root = "/home/foo/first/"
server.errorlog = "/home/foo/logs/first.errorlog"
accesslog.filename = "/home/foo/logs/first.accesslog"
}
$HTTPhost =~ "second.foo.com$" {
server.document-root = "/home/foo/second/"
server.errorlog = "/home/foo/logs/second.errorlog"
accesslog.filename = "/home/foo/logs/second.accesslog"
}

=> error for all host are logged in /home/foo/logs/second.errorlog

-- oliv

History

#1 Updated by Anonymous over 8 years ago

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

#2 Updated by Anonymous about 8 years ago

Also on FreeBSD 6.1 running lighttpd-1.4.11 (ssl)

-- lighttpd

#3 Updated by Anonymous about 8 years ago

Also on Debian sarge running lighttpd 1.4.12

-- dp

#4 Updated by tcsoft about 8 years ago

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

#5 Updated by darix about 8 years ago

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.

#6 Updated by Anonymous almost 8 years ago

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

#7 Updated by Anonymous almost 8 years ago

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

-- Jan Scholten

#8 Updated by Anonymous about 7 years ago

Also on Fedora 7 running lighttpd 1.4.16.

-- Aleksey Klimov

#9 Updated by Anonymous almost 7 years ago

Also on lighttpd 1.4.18

#10 Updated by Anonymous almost 7 years ago

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

-- grin

#11 Updated by Anonymous almost 7 years ago

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

#12 Updated by stbuehler almost 7 years ago

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.

#13 Updated by dandv over 6 years ago

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?

#14 Updated by dandv over 6 years ago

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.

#15 Updated by stbuehler over 6 years ago

  • Status changed from New to Fixed
  • Resolution set to wontfix
  1. You have one lighttpd running, so one error.log. For your applications you should use extra error logs if you need separate ones.
  2. stage and prod running on in the same webserver instance? Just run a second lighttpd...
  3. The code isn't designed for this - too much work in 1.4 and 1.5

#16 Updated by stbuehler about 6 years ago

  • Status changed from Fixed to Wontfix

#17 Updated by dandv almost 6 years ago

  • Status changed from Wontfix to Reopened

Please consider implementing this feature. Nginx supports separating error logs per virtual host: http://article.gmane.org/gmane.comp.web.nginx.english/1628

#18 Updated by stbuehler almost 6 years ago

  • Status changed from Reopened to Wontfix
  • Patch available set to No

#19 Updated by Dark almost 6 years ago

  • Status changed from Wontfix to Reopened

One more try to reopen this annoying "bug" =)

#20 Updated by stbuehler almost 6 years ago

  • Status changed from Reopened to Wontfix

#21 Updated by dandv almost 6 years ago

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?

#22 Updated by slynko almost 6 years ago

  • Status changed from Wontfix to Reopened
  • Target version changed from 1.5.0 to 1.4.22

I also vote for this feature

#23 Updated by stbuehler almost 6 years ago

  • Status changed from Reopened to Wontfix

It's not about how many people want this or what other httpd servers are doing. I will not change the core in 1.4 for this ("stable" version). I probably won't have the time to review such a patch for 1.5 and sandbox already has this feature.

If you want a separate error log for the *cgi backends, just provide a patch.

PS: It is really annoying to close this bug twice a week... and that is time in which I could have done way better things for lighty...

#24 Updated by mk over 5 years ago

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).

#25 Updated by somsy about 3 years ago

  • Status changed from Wontfix to Reopened
  • Target version changed from 1.4.22 to 1.4.x

Maybe stbuehler has cooled off now ("it is really annoying to close this bug twice a week" .. come on, man, toughen up and respect your users! after all, we all know by now that one ignores one's user base at risk of losing it!), so I'm reopening this bug, to reiterate: this is important and, frankly speaking, not that difficult. Lame workarounds are lame.

#26 Updated by stbuehler about 3 years ago

  • Status changed from Reopened to Invalid
  • Priority changed from High to Normal
  • Target version deleted (1.4.x)
  • Missing in 1.5.x set to No

#27 Updated by programmador over 2 years ago

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?

#28 Updated by stbuehler over 2 years ago

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.

#29 Updated by Torxed 5 days ago

  • Status changed from Invalid to Reopened

#30 Updated by Torxed 5 days ago

  • Target version set to 1.5.0

darix wrote:

yes lighttpd supports only one error log. but that doesnt render vhosts useless. vhosts work outside of shared hosting environments very well too. yes this is a missing features that makes it harder to use lighttpd in shared hosting environments.
but in the end it is your decision if lighttpd will work in your setup or not.

for 1.5 we plan to fix this.

Why is there no mention of this on the 1.5 roadmap?
This has been bugging me for ages now. And yea fair enough, I can switch software but then again I wouldn't want to seeing as this was informed 6 years ago that it would be fixed.

Quote from: http://redmine.lighttpd.net/issues/1257

I'm not interested in the error log as much as i am in the access-log, can this be a feature in 1.5 or not?

#31 Updated by darix 5 days ago

  • Status changed from Reopened to Invalid

1.5 branch is dead. lighttpd2 replaced it.

see http://redmine.lighttpd.net/projects/lighttpd2

Also available in: Atom