Project

General

Profile

Actions

Bug #3239

closed

syslog level set to error for messages that are not errors

Added by Hawk777 2 months ago. Updated about 1 month ago.

Status:
Fixed
Priority:
Normal
Category:
core
Target version:
ASK QUESTIONS IN Forums:
No

Description

The message “server started (lighttpd/versionnumber)” is not an error, but it gets sent to syslog at LOG_ERR level. I’m not sure if there are any other log messages that are generated with inappropriate levels. “DEPRECATED: do not set server options in conditionals” seems like it should be LOG_NOTICE or LOG_WARN (unless it’s actually fatal, which “DEPRECATED” does not imply to me), and “WARNING: %s must be in global scope or…” likewise. Various debug messages should probably be LOG_DEBUG, too, of which there are a handful at least in configfile-glue.c; again, I haven’t audited the full tree, just showing a few examples.


Files

multiline-debug.patch (1.57 KB) multiline-debug.patch Change some log_error_multiline to log_debug_multiline Hawk777, 2024-01-08 06:37
Actions #1

Updated by gstrauss 2 months ago

Everything that calls log_error() in lighttpd gets sent to the error log.
If the error log is sent to syslog, then everything sent to the error log is sent with level LOG_ERR.

This is long-standing behavior.

While you are correct that lighttpd could be more precise in labelling the log messages with different severities, this is not currently done. It is not like there is a mistake in one or two messages, but rather that the levels are not marked on each message and the levels are not passed as a parameter to the logger.

Therefore, while you are correct that this is a limitation in lighttpd, I may end up closing this issue as "Won't Fix".


Separately, for mod_accesslog, LOG_INFO is used by default, and that is configurable with accesslog.syslog-level.

Actions #2

Updated by gstrauss 2 months ago

  • Status changed from New to Wontfix
  • Target version deleted (1.4.xx)
Actions #3

Updated by Hawk777 2 months ago

Therefore, while you are correct that this is a limitation in lighttpd, I may end up closing this issue as "Won't Fix".

Does that mean you’d accept a patch, if at some point I were to get around to writing one?

Actions #4

Updated by gstrauss 2 months ago · Edited

Does that mean you’d accept a patch, if at some point I were to get around to writing one?

Probably not. I am not convinced of the value of such a patch that could touch over 1000 lines of code.

lighttpd1.4/src$ grep log_error *.c | wc -l
1037
Actions #5

Updated by gstrauss 2 months ago

I do appreciate that you asked the question.

Actions #6

Updated by gstrauss 2 months ago

Various approaches to passing syslog message priority resulted in large increases in code size.

There are some experimental commits on my development branch
https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/personal/gstrauss/master

If you find the time and have the inclination, you're welcome to submit patches for discussion which update various call sites e.g. from log_error() to log_debug() and from log_error_multiline() to log_debug_multiline().

Making changes to call sites is a behavior change and would have to be announced with the next lighttpd release. Patches will be considered.

Actions #7

Updated by Hawk777 about 2 months ago

If you find the time and have the inclination, you're welcome to submit patches for discussion which update various call sites e.g. from log_error() to log_debug() and from log_error_multiline() to log_debug_multiline().

I see you added macros for the other levels as well, not just error and debug. Should I use those macros as well, if it seems appropriate for a given call site?

How do you prefer I send those patches? I looked around a bit but wasn’t able to find documentation for contributors—for example, do you want patches by e-mail, attached to this ticket, in a Git repo, or something else? Any preference on formatting of commit messages? That kind of thing.

Actions #8

Updated by gstrauss about 2 months ago

Minimum requirement is a unified diff, which may be attached here or in the lighttpd Development forum.
You may alternatively submit a pull request to https://github.com/lighttpd/lighttpd1.4/

I suggest you start with a small, focused patch, such as changing appropriate calls from log_error_multiline() to log_debug_multiline().

Actions #9

Updated by Hawk777 about 2 months ago

Great, here’s a patch for three of the five calls to `log_error_multiline`. They’re all controlled by config directives in the `debug.` namespace, so these seemed like they should probably be debug, though `log-request-header-on-error` could be argued to be higher than that. The other two occurrences of `log_error_multiline` seemed like they should probably stay as errors: stderr from a FastCGI script, and a Lua raised error from `mod_magnet`, both seem error-like to me.

Actions #10

Updated by gstrauss about 2 months ago

Correct. Three of the five calls are controlled by debug directives.
How would you like to be credited in the commit? 'Hawk777' or something else?
I typically add a "(thx Hawk777)" in commits with contributor patches.

though `log-request-header-on-error` could be argued to be higher than that.

No. That is a stretch and a poor hand-waving argument. On the other hand, a more solid argument grounded in reality is the observation that `debug.log-request-header-on-error` controls optional debug trace and is named as such. Rejected request headers are rejected regardless of whether or not additional debug trace is sent to the logs. The debug trace is optional.

Please stop hand-waving stupid stuff. Make a proper defense of your statements or avoid sharing your hot takes and groundless opinions. (They are groundless because you did not provide any grounding.)

Actions #11

Updated by gstrauss about 2 months ago

  • Status changed from Wontfix to Fixed
  • Target version set to 1.4.74
Actions #12

Updated by Hawk777 about 1 month ago

How would you like to be credited in the commit? 'Hawk777' or something else? I typically add a "(thx Hawk777)" in commits with contributor patches.

That’s fine, thanks.

No. That is a stretch and a poor hand-waving argument. On the other hand, a more solid argument grounded in reality is the observation that `debug.log-request-header-on-error` controls optional debug trace and is named as such. Rejected request headers are rejected regardless of whether or not additional debug trace is sent to the logs. The debug trace is optional.

I agree it’s under the category of “debug”; that having been said, it’s also something that only applies when there’s an error (albeit an external one). Would you mind clarifying what your position is on whether a failure of something outside Lighttpd itself (HTTP client, CGI process, HTTP proxy backend server, or whatever) is considered an error or not for logging purposes? Personally I’d rather not have an error reported every time some random network scanner decides to send a funny-looking request which my web server rejects; if the attack it was probing for fails, then it’s just noise. It sounds like you probably agree, but I’d like to be sure you want that as an overall rule rather than in this one specific case (should I find other log messages elsewhere that are not controlled by something with `debug` in the name, for example).

Actions #13

Updated by gstrauss about 1 month ago · Edited

Would you mind clarifying what your position is on whether a failure of something outside Lighttpd itself (HTTP client, CGI process, HTTP proxy backend server, or whatever) is considered an error or not for logging purposes?

Personally I’d rather not have an error reported every time some random network scanner decides to send a funny-looking request which my web server rejects; if the attack it was probing for fails, then it’s just noise. It sounds like you probably agree, but I’d like to be sure you want that as an overall rule rather than in this one specific case (should I find other log messages elsewhere that are not controlled by something with `debug` in the name, for example).

I'm not sure you've gotten the point yet. I am wholly uninterested in EVERYTHING from you which contains "my opinion" or "personally" or anything like it because you have been inept at providing any real observations or grounding to back up those opinions. Hand-waving theoreticals are theoreticals.

In that vein, what problem(s) are you trying to solve? lighttpd is not a new piece of software. "What the code does" is exactly the behavior that answers your question "What should it do?". You have not identified a specific error message or messages which bother you (besides those behind debug directives, which have already been addressed).

If you have new demonstrable examples of noise in your log from scanners, and you can intelligently make a case WITHOUT injecting any of your worthless opinions, then we can have a conversation about it. lighttpd has in the past put some logging behind config options, e.g. debug.log-ssl-noise, so a conversation is possible. To set expectations, what WILL NOT happen is unnecessary changes to match your personal choices for syslog. If you are incapable of filtering your syslog queries, then I suggesting learning how to do so.

If there is something in lighttpd logging that bothers you, but that lighttpd developers (me) do not want to change in lighttpd, then one possible solution for you is to use a piped-logger server.errorlog = "|/path/to/your/custom/filter.py" and to filter some messages and map others to your desired syslog level, and then syslog them from your custom filter.py program. Please don't waste my time if you can not articulate -- omitting opinions -- why a specific error message is causing actual, measurable impact in the real world, not just in your head.

Actions #14

Updated by Hawk777 about 1 month ago

You have not identified a specific error message or messages which bother you (besides those behind debug directives, which have already been addressed).

I actually did, in the very first message of this ticket: “server started” is not an error. If you agree, then let’s limit the scope of this ticket to that specific message and avoid considering my opinion on any others. If you disagree, then I guess drop this altogether.

Actions #15

Updated by gstrauss about 1 month ago

let's limit the scope of this ticket

This ticket is already closed and resolved, marked fixed. It is obvious to me that you haven't bothered to look at commits on the lighttpd git master branch that were pushed over a week ago, and yet you continue talking, so here, I am going to stop.

Actions #16

Updated by Hawk777 about 1 month ago

Thank you for that change.

Actions

Also available in: Atom