FYI currently we log to stderr, not stdout. Does this matter for Docker? Consensus seems to be to leave logging as it by default, with a configure time option to log to a file. This is a bit annoying given the way that rebar's overlay functionality works but I'll sort it out.
-Joan ----- Original Message ----- > From: "Clemens Stolle" <[email protected]> > To: [email protected] > Sent: Tuesday, August 9, 2016 4:52:22 AM > Subject: Re: [PROPOSAL] CouchDB 2.0 log to ./var/log/couchdb.log by default > > Just chiming in here from a docker perspective. > > For docker containers it is advisable to only log to stdout. > So, as long as there is an option to disable logging to file, I'm > fine > with anything. > > Am Mi, 3. Aug 2016, um 17:59, schrieb Paul Davis: > > Just a heads up that the file writer doesn't require copy/truncate. > > It > > checks every 30s or so to see if the inode for its path changed and > > re-opens and starts writing to a new file if it has. > > > > On Tue, Aug 2, 2016 at 3:37 PM, Joan Touzet <[email protected]> > > wrote: > > > 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" <[email protected]> > > > To: [email protected] > > > 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 > > >> <[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. > > > >
