Project

General

Profile

Feature #2800

lighttpd needs config option for syslog facility

Added by philipp 6 months ago. Updated 6 months ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
core
Target version:
Start date:
2017-03-15
Due date:
% Done:

100%

Estimated time:
Missing in 1.5.x:

Description

A lot of things log as LOG_DAEMON and you might not always have time to separate the wheat from the chaff.

Being able to specify a logging facility like:

server.syslog-facility = "local3" 

would really be handy.

Associated revisions

Revision a8561450 (diff)
Added by gstrauss 6 months ago

[core] server.syslog-facility (fixes #2800)

server.syslog-facility = "daemon"

x-ref:
"lighttpd needs config option for syslog facility"
https://redmine.lighttpd.net/issues/2800

Revision ad6c703a (diff)
Added by gstrauss 6 months ago

[core] server.syslog-facility (use -1 for unset) (#2800)

(thx philipp)

x-ref:
"lighttpd needs config option for syslog facility"
https://redmine.lighttpd.net/issues/2800

History

#1 Updated by gstrauss 6 months ago

  • Tracker changed from Bug to Feature

Please do not file feature requests as bugs.
(Please take note that this is the second time I am making this request to you within the span of two days.)

There is a drop-down box for Tracker when filing a new issue. While the default is "Bug", you should change it to "Feature" when making a feature request.

Alternatively, instead of filing an issue, start a discussion in the Support forum: https://redmine.lighttpd.net/projects/lighttpd/boards/2

#2 Updated by philipp 6 months ago

Question of perspective, really.

Not being able to do things that homologous packages provide as part of their core functionality could be considered a design shortcoming (and hence a bug).

Being able to do things above and beyond what might be considered baseline functionality most people would agree is a feature.

I guess the question of "where should the baseline" be is a point that reasonable people have disagree upon.

If the point of a package is to be stripped down and provide minimal functionality in exchange for small footprint, then one could argue that drawing a parallel baseline to other packages not having this constraint is an apples to oranges comparison.

At the same time, one could also argue that if one supports using syslog at all (and therefore, potentially, remote logging) then being able to specify the facility is not optional but indeed a necessity, since having lots of nodes hosting many services all funneling into a centralized logging facility requires at a minimum some basic forms of triage to make the logging even feasible.

The perspective of the developer about what is a bug vs what is a feature often comes down to "what could I reasonable punt and not feel bad about"?

The perspective of the user about what is a bug vs what is a feature, by contrast, is "what do I need to have to deploy this vs what would I like to have"?

As developers, we don't always have perfect insight into how our software gets used "out there".

I'm often surprised myself reading bug reports about some of the usage scenarios people come up with.

For the record, it's not that I don't know how to track an issue. It's that we disagree about what's potentially a feature vs a bug.

That someone might be more prone to categorizing issues as bugs doesn't mean they're adversarial: just that their requirements are different, and perhaps even more numerous.

#3 Updated by gstrauss 6 months ago

  • Priority changed from Normal to Low

[...] would really be handy.

Those are your words above. They describe a feature.

That someone might be more prone to categorizing issues as bugs doesn't mean they're adversarial: just that their requirements are different, and perhaps even more numerous.

You may not be adversarial, but you are unnecessarily argumentative, IMNSHO.

Allow me to definitively conclude one "argument" over what certain words mean by specifying how "bug" and "feature" are defined here for this open source project, run by volunteers donating their time and energy. These definitions are not open to debate except by the project maintainers.

  • A "bug" is behavior that does not work as documented (including RFC-required behavior that is documented as being supported in lighttpd) or a security issue.
  • A "feature" is anything else.
  • Project maintainers may change the documentation, which may change what was a "bug" into a "feature" request.
  • The only authoritative documentation is on the lighttpd website, not other sites or documentation maintained by distros.

I choose not to engage you further beyond saying this: if you would like to have a constructive conversation and have any chance of me spending any of my time on your feature requests, please change your tone and approach.

You appear to me to be a capable coder based on your previous pull request to the lighttpd github repo, and I do make time to review and comment on pull requests, though I make no guarantee of accepting them. Therefore, I encourage you to submit small patches to github for the feature(s) you desire. At the moment, I have higher priorities than arguing semantics on low-priority feature requests.

#4 Updated by gstrauss 6 months ago

  • Status changed from New to Patch Pending
  • Target version changed from 1.4.x to 1.4.46

#5 Updated by gstrauss 6 months ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

#6 Updated by philipp 6 months ago

I'm looking at the following:

        int facility = 0;
...
                  #ifdef LOG_KERN
                   ,{ "kern",     LOG_KERN }
                  #endif
...
                if (0 == facility) {
                        log_error_write(srv, __FILE__, __LINE__, "SBS",
                                        "unrecognized server.syslog-facility: \"",
                                        srv->srvconf.syslog_facility,
                                        "\"; defaulting to \"daemon\" facility");
                }
...
       openlog("lighttpd", LOG_CONS | LOG_PID, facility ? facility : LOG_DAEMON);

but consulting sys/syslog.h on my Linux system, I see:

/* facility codes */
#define LOG_KERN        (0<<3)  /* kernel messages */

so 0 is actually a valid facility.

Perhaps this should have been better written as:

        int facility = -1;
...
                if (-1 == facility) {
                        log_error_write(srv, __FILE__, __LINE__, "SBS",
                                        "unrecognized server.syslog-facility: \"",
                                        srv->srvconf.syslog_facility,
                                        "\"; defaulting to \"daemon\" facility");
                }
...
       openlog("lighttpd", LOG_CONS | LOG_PID, (facility != -1) ? facility : LOG_DAEMON);

using -1 as the sentinel value instead.

#7 Updated by gstrauss 6 months ago

good catch. will patch as suggested

at the same time, I find it hard to think any justification for using LOG_KERN from lighttpd, which is most definitely not the kernel. :/

#8 Updated by philipp 6 months ago

good catch. will patch as suggested

Thanks.

at the same time, I find it hard to think any justification for using LOG_KERN from lighttpd, which is most definitely not the kernel. :/

True enough. But, at least it's complete and you cover all the bases!

Also available in: Atom