Re: [PROPOSAL] CouchDB 2.0 log to ./var/log/couchdb.log by default

[Joan Touzet]

Yeah, I understand these reservations. I also learned that systemd
handles stdout/stderr logging on its own now, so if that's the
default on the bulk of popular UNIXes, perhaps this is a retrograde
choice.

That said it is the *only* choice I can support on Windows, where
there is no system-wide logging service capable of handling the sort
of volume of logs we generate. (By comparison, Microsoft's own IIS
web server logs directly to its own logfile, or optionally to an
ODBC connection, not to the system Event Logger service, which it
only uses to log startup/shutdown/critical errors). At the very
least I will have to search-and-replace at Windows installer creation
time to log to a file and live with the large-log-file-blows-up-disk
problem there, otherwise we simply lose logs into the aether.

We could add flags into ./configure to log appropriately to a file
or to stderr if someone is energetic enough to add the support code.
I'm just not sure how that plays nicely with reltool overlay support,
though. And we still don't have a clear answer as to what the default
would be (if you don't specify --log-file or --log-stderr).

-Joan

- Original Message -
From: "Robert Samuel Newson" 
To: dev@couchdb.apache.org
Sent: Tuesday, August 2, 2016 4:29:33 PM
Subject: Re: [PROPOSAL] CouchDB 2.0 log to ./var/log/couchdb.log by default

My concern is that (and we've seen this with BigCouch), folks won't configure 
log rotation until they have either a whopping great log file or, more 
typically, been woken by a paging system as their filesystem hit 100%.

Given this method of logging also forces a copytruncate approach to rotation 
(i.e, a hackish workaround), I'm not keen (but not vetoing either).

There's no one right answer here. Folks that run couchdb under runit or systemd 
will get log capture and rotation for free with the stderr approach, for 
example.

Can we make this an active choice so we're out of this guessing game? One 
suggestion would be to default to a configuration that logs nothing anywhere 
except for a giant warning to configure logging. I'm thinking of log4j's 
approach here.

B.


> On 2 Aug 2016, at 21:20, Paul J Davis  wrote:
> 
> Seems reasonable to me. I wonder if we should add a stdout log line that 
> indicates where logs are going? Would be easy to add that as a module 
> callback so it would work for stderr, file, and syslog. 
> 
>> On Aug 2, 2016, at 2:36 PM, Joan Touzet  wrote:
>> 
>> Presently, CouchDB 2.0 logs only to stderr. I have opened a PR
>> to switch this behaviour to log to the ./var/log/couchdb.log
>> release-local file by default:
>> 
>> https://github.com/apache/couchdb/pull/435
>> 
>> This behaviour is easily overridden in the default.ini/local.ini
>> files if desired.
>> 
>> I'm not sure if this is wanted by all stakeholders, so I haven't
>> merged it into master. Please let me know either here or in the PR
>> your thoughts. My intent is to merge this change by lazy consensus.

Re: [PROPOSAL] CouchDB 2.0 log to ./var/log/couchdb.log by default

[Joan Touzet]

It's not proposed to log to /var/log, but ./var/log. Big difference :)

I'll respond to the other point separately.

- Original Message -
From: "Robert Samuel Newson" 
To: dev@couchdb.apache.org
Sent: Tuesday, August 2, 2016 4:30:12 PM
Subject: Re: [PROPOSAL] CouchDB 2.0 log to ./var/log/couchdb.log by default

oh, as for /var/log/, that'd be a violation of LSB policy, right? That's not 
our place to play unless invited.


> On 2 Aug 2016, at 21:29, Robert Samuel Newson  wrote:
> 
> My concern is that (and we've seen this with BigCouch), folks won't configure 
> log rotation until they have either a whopping great log file or, more 
> typically, been woken by a paging system as their filesystem hit 100%.
> 
> Given this method of logging also forces a copytruncate approach to rotation 
> (i.e, a hackish workaround), I'm not keen (but not vetoing either).
> 
> There's no one right answer here. Folks that run couchdb under runit or 
> systemd will get log capture and rotation for free with the stderr approach, 
> for example.
> 
> Can we make this an active choice so we're out of this guessing game? One 
> suggestion would be to default to a configuration that logs nothing anywhere 
> except for a giant warning to configure logging. I'm thinking of log4j's 
> approach here.
> 
> B.
> 
> 
>> On 2 Aug 2016, at 21:20, Paul J Davis  wrote:
>> 
>> Seems reasonable to me. I wonder if we should add a stdout log line that 
>> indicates where logs are going? Would be easy to add that as a module 
>> callback so it would work for stderr, file, and syslog. 
>> 
>>> On Aug 2, 2016, at 2:36 PM, Joan Touzet  wrote:
>>> 
>>> Presently, CouchDB 2.0 logs only to stderr. I have opened a PR
>>> to switch this behaviour to log to the ./var/log/couchdb.log
>>> release-local file by default:
>>> 
>>> https://github.com/apache/couchdb/pull/435
>>> 
>>> This behaviour is easily overridden in the default.ini/local.ini
>>> files if desired.
>>> 
>>> I'm not sure if this is wanted by all stakeholders, so I haven't
>>> merged it into master. Please let me know either here or in the PR
>>> your thoughts. My intent is to merge this change by lazy consensus.
> 

Re: [PROPOSAL] CouchDB 2.0 log to ./var/log/couchdb.log by default

[Robert Samuel Newson]

oh, as for /var/log/, that'd be a violation of LSB policy, right? That's not 
our place to play unless invited.


> On 2 Aug 2016, at 21:29, Robert Samuel Newson  wrote:
> 
> My concern is that (and we've seen this with BigCouch), folks won't configure 
> log rotation until they have either a whopping great log file or, more 
> typically, been woken by a paging system as their filesystem hit 100%.
> 
> Given this method of logging also forces a copytruncate approach to rotation 
> (i.e, a hackish workaround), I'm not keen (but not vetoing either).
> 
> There's no one right answer here. Folks that run couchdb under runit or 
> systemd will get log capture and rotation for free with the stderr approach, 
> for example.
> 
> Can we make this an active choice so we're out of this guessing game? One 
> suggestion would be to default to a configuration that logs nothing anywhere 
> except for a giant warning to configure logging. I'm thinking of log4j's 
> approach here.
> 
> B.
> 
> 
>> On 2 Aug 2016, at 21:20, Paul J Davis  wrote:
>> 
>> Seems reasonable to me. I wonder if we should add a stdout log line that 
>> indicates where logs are going? Would be easy to add that as a module 
>> callback so it would work for stderr, file, and syslog. 
>> 
>>> On Aug 2, 2016, at 2:36 PM, Joan Touzet  wrote:
>>> 
>>> Presently, CouchDB 2.0 logs only to stderr. I have opened a PR
>>> to switch this behaviour to log to the ./var/log/couchdb.log
>>> release-local file by default:
>>> 
>>> https://github.com/apache/couchdb/pull/435
>>> 
>>> This behaviour is easily overridden in the default.ini/local.ini
>>> files if desired.
>>> 
>>> I'm not sure if this is wanted by all stakeholders, so I haven't
>>> merged it into master. Please let me know either here or in the PR
>>> your thoughts. My intent is to merge this change by lazy consensus.
> 

Re: [PROPOSAL] CouchDB 2.0 log to ./var/log/couchdb.log by default

[Robert Samuel Newson]

My concern is that (and we've seen this with BigCouch), folks won't configure 
log rotation until they have either a whopping great log file or, more 
typically, been woken by a paging system as their filesystem hit 100%.

Given this method of logging also forces a copytruncate approach to rotation 
(i.e, a hackish workaround), I'm not keen (but not vetoing either).

There's no one right answer here. Folks that run couchdb under runit or systemd 
will get log capture and rotation for free with the stderr approach, for 
example.

Can we make this an active choice so we're out of this guessing game? One 
suggestion would be to default to a configuration that logs nothing anywhere 
except for a giant warning to configure logging. I'm thinking of log4j's 
approach here.

B.


> On 2 Aug 2016, at 21:20, Paul J Davis  wrote:
> 
> Seems reasonable to me. I wonder if we should add a stdout log line that 
> indicates where logs are going? Would be easy to add that as a module 
> callback so it would work for stderr, file, and syslog. 
> 
>> On Aug 2, 2016, at 2:36 PM, Joan Touzet  wrote:
>> 
>> Presently, CouchDB 2.0 logs only to stderr. I have opened a PR
>> to switch this behaviour to log to the ./var/log/couchdb.log
>> release-local file by default:
>> 
>> https://github.com/apache/couchdb/pull/435
>> 
>> This behaviour is easily overridden in the default.ini/local.ini
>> files if desired.
>> 
>> I'm not sure if this is wanted by all stakeholders, so I haven't
>> merged it into master. Please let me know either here or in the PR
>> your thoughts. My intent is to merge this change by lazy consensus.

Re: [PROPOSAL] CouchDB 2.0 log to ./var/log/couchdb.log by default

[Paul J Davis]

Seems reasonable to me. I wonder if we should add a stdout log line that 
indicates where logs are going? Would be easy to add that as a module callback 
so it would work for stderr, file, and syslog. 

> On Aug 2, 2016, at 2:36 PM, Joan Touzet  wrote:
> 
> Presently, CouchDB 2.0 logs only to stderr. I have opened a PR
> to switch this behaviour to log to the ./var/log/couchdb.log
> release-local file by default:
> 
>  https://github.com/apache/couchdb/pull/435
> 
> This behaviour is easily overridden in the default.ini/local.ini
> files if desired.
> 
> I'm not sure if this is wanted by all stakeholders, so I haven't
> merged it into master. Please let me know either here or in the PR
> your thoughts. My intent is to merge this change by lazy consensus.

[PROPOSAL] CouchDB 2.0 log to ./var/log/couchdb.log by default

[Joan Touzet]

Presently, CouchDB 2.0 logs only to stderr. I have opened a PR
to switch this behaviour to log to the ./var/log/couchdb.log
release-local file by default:

  https://github.com/apache/couchdb/pull/435

This behaviour is easily overridden in the default.ini/local.ini
files if desired.

I'm not sure if this is wanted by all stakeholders, so I haven't
merged it into master. Please let me know either here or in the PR
your thoughts. My intent is to merge this change by lazy consensus.