Feature #2122
closedInclude host in error log
Description
Could you include the host name as well?
2009-12-17 14:34:25: (mod_fastcgi.c.2569) unexpected end-of-file (perhaps the fastcgi process died): pid: 0 socket: unix:/tmp/php.socket-1
2009-12-17 14:34:25: (mod_fastcgi.c.3354) response not received, request sent: 1071 on socket: unix:/tmp/php.socket-1 for /details.php?id=137679, closing connection
Updated by stbuehler almost 15 years ago
- Target version changed from 1.4.26 to 1.4.27
Updated by lonnyk almost 15 years ago
There are only two ways I can see this getting done and I'd like an opinion:
1) Pass in con, or con_server_name, to log_error_write
2) Instead of popping con out of srv for the current connection we can declare a connection struct inside of the server struct that would be that current connection
Please let me know your thoughts on this.
Updated by stbuehler almost 15 years ago
- Target version changed from 1.4.27 to 1.4.x
Neither one is acceptable in my eyes; i don't want to change the api, and i don't like a global state.
That leaves the 3rd option: include the hostname manually in the log messages where it is needed.
Updated by Olaf-van-der-Spek almost 15 years ago
How is the "/details.php?id=137679" bit passed? Can't that bit be extended to a full URL?
Updated by lonnyk almost 15 years ago
In your particular error message the con->uri.query is passed in. It can be extended to the full URL by first passing in the con->server_name, however, that would only be for your specific log line as opposed to all helpful places.
stbuehler - I don't understand what you mean w/ your 3rd option. The hostname isn't available in log_error_write unless it is passed in - which would be my first option of passing in con->server_name to log_error_write where needed.
Additionally, this bug was previously marked w/ a target version of 1.4.27 and is now 1.4.x. Are you trying to imply that it's most likely not even worth trying to change b/c it wont get committed to 1.4.x or simply that it's not a priority for 1.4.27?
Updated by Olaf-van-der-Spek almost 15 years ago
He means manually including it in the message text itself, like the query.
i don't want to change the api, and i don't like a global state.
In that case, add a second log_error_write function that does take a URL as parameter.
Updated by stbuehler almost 15 years ago
- I don't think it is worth the effort to change/extend the api; and i don't think you need the hostname in every error.
- Yes, this feature has no priority in my eyes. You have a timestamp and url+querystring, that should be good enough to find the matching request in the access.log
- Whether patches get accepted depends on many things... how useful are they, how much time do i need to review/test them, ... 1.4.x doesn't mean we won't accept patches.
Updated by gstrauss over 8 years ago
- Status changed from New to Missing Feedback
This request is not well-scoped. "Better error messages" is, of course, something that would be nice, but is very vague.
While some people will, no doubt, find it useful were lighttpd to provide the full request, plus server name, plus ..., in every error message, that amount of information is not absolutely necessary for troubleshooting every error in the error log. Providing such information would be quite invasive to the code, touching many, many lines. Then, even if that were done, there would, no doubt, be requests to add more information to the error log.
tl;dr: making the error log prefix configurable like mod_accesslog is not a current priority in lighttpd development.
That said, if you have specific error messages you are receiving from mod_fastcgi (or other module), would benefit from additional info in the error log message, and can point to a specific line in mod_fastcgi (or other module), you may request that additional information be added to that specific call to log_error_write(). Such a patch is much more likely to be accepted.
Updated by gstrauss 10 months ago
- Is duplicate of Feature #1406: Add host and full URI to some error trace added
Also available in: Atom