Lighttpd

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.

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.

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. :/

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!