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" <[email protected]> To: [email protected] 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. >
