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 <d...@muse.net.nz> wrote: > On 1 June 2012 17:09, Tim Tisdall <tisd...@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 >
