https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412017-03-16T05:14:47Zlighty labsLighttpd - Feature #2800: lighttpd needs config option for syslog facilityhttps://redmine.lighttpd.net/issues/2800?journal_id=109572017-03-16T05:14:47Zgstrauss
<ul><li><strong>Tracker</strong> changed from <i>Bug</i> to <i>Feature</i></li></ul><p>Please do not file feature requests as bugs.<br />(Please take note that this is the second time I am making this request to you within the span of two days.)</p>
<p>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.</p>
<p>Alternatively, instead of filing an issue, start a discussion in the Support forum: <a class="external" href="https://redmine.lighttpd.net/projects/lighttpd/boards/2">https://redmine.lighttpd.net/projects/lighttpd/boards/2</a></p> Lighttpd - Feature #2800: lighttpd needs config option for syslog facilityhttps://redmine.lighttpd.net/issues/2800?journal_id=109582017-03-16T05:41:10Zphilipp
<ul></ul><p>Question of perspective, really.</p>
<p>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).</p>
<p>Being able to do things above and beyond what might be considered baseline functionality most people would agree is a feature.</p>
<p>I guess the question of "where should the baseline" be is a point that reasonable people have disagree upon.</p>
<p>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.</p>
<p>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.</p>
<p>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"?</p>
<p>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"?</p>
<p>As developers, we don't always have perfect insight into how our software gets used "out there".</p>
<p>I'm often surprised myself reading bug reports about some of the usage scenarios people come up with.</p>
<p>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.</p>
<p>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.</p> Lighttpd - Feature #2800: lighttpd needs config option for syslog facilityhttps://redmine.lighttpd.net/issues/2800?journal_id=109592017-03-16T06:04:22Zgstrauss
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul><blockquote>
<p>[...] would really be handy.</p>
</blockquote>
<p>Those are your words above. They describe a feature.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>You may not be adversarial, but you are unnecessarily argumentative, IMNSHO.</p>
<p>Allow me to definitively conclude one "argument" over what certain words mean by specifying how "bug" and "feature" are defined <em>here</em> 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.</p>
<ul>
<li>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.</li>
<li>A "feature" is anything else.</li>
<li>Project maintainers may change the documentation, which may change what was a "bug" into a "feature" request.</li>
<li>The only authoritative documentation is on the lighttpd website, not other sites or documentation maintained by distros.</li>
</ul>
<p>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.</p>
<p>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.</p> Lighttpd - Feature #2800: lighttpd needs config option for syslog facilityhttps://redmine.lighttpd.net/issues/2800?journal_id=109602017-03-20T03:56:22Zgstrauss
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Patch Pending</i></li><li><strong>Target version</strong> changed from <i>1.4.x</i> to <i>1.4.46</i></li></ul> Lighttpd - Feature #2800: lighttpd needs config option for syslog facilityhttps://redmine.lighttpd.net/issues/2800?journal_id=109612017-03-20T04:00:06Zgstrauss
<ul><li><strong>Status</strong> changed from <i>Patch Pending</i> to <i>Fixed</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>Applied in changeset <a class="changeset" title="[core] server.syslog-facility (fixes #2800) server.syslog-facility = "daemon" x-ref: "lighttp..." href="https://redmine.lighttpd.net/projects/lighttpd/repository/14/revisions/a8561450a58d2b708195be5a73e75a0c498819eb">a8561450a58d2b708195be5a73e75a0c498819eb</a>.</p> Lighttpd - Feature #2800: lighttpd needs config option for syslog facilityhttps://redmine.lighttpd.net/issues/2800?journal_id=109622017-03-20T23:16:58Zphilipp
<ul></ul><p>I'm looking at the following:</p>
<pre>
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);
</pre>
<p>but consulting <code>sys/syslog.h</code> on my Linux system, I see:</p>
<pre>
/* facility codes */
#define LOG_KERN (0<<3) /* kernel messages */
</pre>
<p>so <code>0</code> is actually a valid facility.</p>
<p>Perhaps this should have been better written as:</p>
<pre>
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);
</pre>
<p>using <code>-1</code> as the sentinel value instead.</p> Lighttpd - Feature #2800: lighttpd needs config option for syslog facilityhttps://redmine.lighttpd.net/issues/2800?journal_id=109632017-03-21T00:20:00Zgstrauss
<ul></ul><p>good catch. will patch as suggested</p>
<p>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. :/</p> Lighttpd - Feature #2800: lighttpd needs config option for syslog facilityhttps://redmine.lighttpd.net/issues/2800?journal_id=109642017-03-21T01:42:11Zphilipp
<ul></ul><blockquote>
<p>good catch. will patch as suggested</p>
</blockquote>
<p>Thanks.</p>
<blockquote>
<p>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. :/</p>
</blockquote>
<p>True enough. But, at least it's complete and you cover all the bases!</p>