couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Tisdall <tisd...@gmail.com>
Subject Re: local.ini settings not taking precedence
Date Fri, 01 Jun 2012 20:56:25 GMT
I have the same config order as you.

It seems to have written the log level change to local.ini .  However, I'm
not sure how to interpret that...  does that mean it's giving local.ini the
highest precedence?

So, I looked at http://localhost:5984/_utils/config.html and it's now
reporting
socket_options  [{nodelay, true}]

This is after I changed local.ini to have the value
socket_option = [{keepalive, true}, {nodelay, true}]

since both default and local.ini say keepalive is true, it seems odd that
it's now dropped...

On Fri, Jun 1, 2012 at 2:15 PM, Dave Cottlehuber <dave@muse.net.nz> wrote:

> On 1 June 2012 17:09, Tim Tisdall <tisdall@gmail.com> wrote:
> > Maybe I'm missing something simple, but my understanding is that
> local.ini
> > values should take precedence over values in default.ini .  However, I'm
> > trying to set nodelay to true for the socket_options and that doesn't
> > appear to be working.
>
>
> Strictly speaking the ini file that's last in the chain takes precedence,
> and
> its also the file that gets changes written to.
>
> You can see which ones are being used and in what order with
>
> $ couchdb -c
> /usr/local/etc/couchdb/default.ini
> /usr/local/etc/couchdb/local.ini
>
> > Here's what's in default.ini :
> > socket_options = [{keepalive, true}, {nodelay, false}]
> >
> > here's what's in local.ini:
> > socket_options = [{nodelay, true}]
> >
> > http://localhost:5984/_utils/config.html is reporting that
> socket_options
> > is equal to:
> > [{keepalive, true}, {nodelay, false}]
> >
> >
> > I've restarted the couchdb server multiple times since making the change,
> > but just noticed now that the change doesn't appear to have been made.
>  I'm
> > using v1.2.0
>
> A restart is not required, the erlang magic picks up the changed config
> for you.
>
> If your config chain above doesn't raise warning bells, can you temporarily
> up the log level to debug, try this:
>
>    COUCH=http://admin:passwd@localhost:5984
>    curl -vXPUT $COUCH/_config/httpd/fake_key -d '"fake_value"'
>
> You should see something like this in your logs:
>
> [Fri, 01 Jun 2012 18:10:23 GMT] [debug] [<0.287.0>] 'PUT'
> /_config/httpd/fake_key {1,1} from "127.0.0.1"
> Headers: [{'Accept',"*/*"},
>          {'Authorization',"Basic YWRtaW46cFGSzc3dk"},
>          {'Content-Length',"12"},
>          {'Content-Type',"application/x-www-form-urlencoded"},
>          {'Host',"localhost:5984"},
>          {'User-Agent',"curl/7.21.4 (universal-apple-darwin11.0)
> libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5"}]
> [Fri, 01 Jun 2012 18:10:23 GMT] [debug] [<0.287.0>] OAuth Params: []
> [Fri, 01 Jun 2012 18:10:23 GMT] [info] [<0.287.0>] 127.0.0.1 - - PUT
> /_config/httpd/fake_key 200
>
> And you should be able to grep for fake_key if needed to see where
> it's being written to.
>
> In fact you can even use upping the log level as a check:
>
>    curl -vXPUT $COUCH/_config/log/level -d '"debug"'
>
> and back to error
>
>    curl -vXPUT $COUCH/_config/log/level -d '"error"'
>
> A+
> Dave
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message