Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of dave@muse.net.nz designates
 209.85.212.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGxYWpbX7raSTRLXEOKLPUTkAqSHD9NN+OUfx77O9CR3nto1hw@mail.gmail.com>
References: 
 <CAGxYWpbX7raSTRLXEOKLPUTkAqSHD9NN+OUfx77O9CR3nto1hw@mail.gmail.com>
Date: Fri, 1 Jun 2012 20:15:02 +0200
Message-ID: 
 <CAHZBNKYtVkHh56NUNEW65Jev3SDuSvLCsygfdGSSdrWmym-mog@mail.gmail.com>
Subject: Re: local.ini settings not taking precedence
From: Dave Cottlehuber <dave@muse.net.nz>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 1 June 2012 17:09, Tim Tisdall <tisdall@gmail.com> wrote:
> Maybe I'm missing something simple, but my understanding is that local.in=
i
> values should take precedence over values in default.ini . =A0However, 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, a=
nd
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 =3D [{keepalive, true}, {nodelay, false}]
>
> here's what's in local.ini:
> socket_options =3D [{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. =
=A0I'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=3Dhttp://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