Things seemed to run despite those errors, but when the logging is in "debug" I can see that the server does restart after outputting those eaccess errors. I see it in my application as getting a blank response from the server.
On Thu, Aug 16, 2012 at 4:06 PM, Paul Davis <paul.joseph.da...@gmail.com> wrote: > Never figured that issue out other than every single time its > mentioned its a red herring. I think its just Erlang doing "WARNING: > Everything is fine." type of logging. > > Odd that beam dies when gdb attaches to it. Not sure if that's > important or not. I've definitely never seen such a thing. > > On Thu, Aug 16, 2012 at 2:19 PM, Tim Tisdall <tisd...@gmail.com> wrote: >> Paul, did you ever solve the eaccess problem you had described here: >> http://mail-archives.apache.org/mod_mbox/couchdb-user/201106.mbox/%3c4e0b304f.5080...@lymegreen.co.uk%3E >> I found that post from doing Google searches for my issue. >> >> On Tue, Aug 14, 2012 at 11:41 PM, Paul Davis >> <paul.joseph.da...@gmail.com> wrote: >>> On Tue, Aug 14, 2012 at 9:38 PM, Tim Tisdall <tisd...@gmail.com> wrote: >>>> I'm still having problems with couchdb, but I'm trying out different >>>> things to see if I can narrow down what the problem is... >>>> >>>> I stopped using fsockopen() in PHP and am using curl now to hopefully >>>> be able to see more debugging info. >>>> >>>> I get an empty response when sending a POST to _bulk_docs. From the >>>> couch logs it seems like the server restarts in the middle of >>>> processing the request. Here's what I have in my logs: (I have no >>>> idea what the _replicator portion is about there, I'm currently not >>>> using it) >>>> >>>> >>>> [Wed, 15 Aug 2012 02:27:30 GMT] [debug] [<0.1255.0>] 'POST' >>>> /app_stats_test/_bulk_docs {1,0} from "127.0.0.1" >>>> Headers: [{'Accept',"*/*"}, >>>> {'Content-Length',"2802300"}, >>>> {'Content-Type',"application/json"}, >>>> {'Host',"localhost:5984"}] >>>> [Wed, 15 Aug 2012 02:27:30 GMT] [debug] [<0.1255.0>] OAuth Params: [] >>>> [Wed, 15 Aug 2012 02:27:45 GMT] [debug] [<0.115.0>] Include Doc: >>>> <<"_design/_replicator">> {1, >>>> >>>> <<91,250,44,153, >>>> >>>> 238,254,43,46, >>>> >>>> 180,150,45,181, >>>> >>>> 10,163,207,212>>} >>>> [Wed, 15 Aug 2012 02:27:45 GMT] [info] [<0.32.0>] Apache CouchDB has >>>> started on http://127.0.0.1:5984/ >>>> >>>> >>>> In my code logs I have the following by running curl in verbose mode: >>>> >>>> * About to connect() to localhost port 5984 (#0) >>>> * Trying 127.0.0.1... * connected >>>> * Connected to localhost (127.0.0.1) port 5984 (#0) >>>>> POST /app_stats_test/_bulk_docs HTTP/1.0 >>>> Host: localhost:5984 >>>> Accept: */* >>>> Content-Type: application/json >>>> Content-Length: 2802300 >>>> >>>> * Empty reply from server >>>> * Connection #0 to host localhost left intact >>>> curl error: 52 : Empty reply from server >>>> >>>> >>>> >>>> I also tried using HTTP/1.1 and I get an empty response after >>>> receiving only a "100 Continue", but the end result appears the same. >>>> >>>> -Tim >>> >>> If you have a request that triggers this, a good way to catch it is like >>> such: >>> >>> $ /usr/local/bin/couchdb # or however you start it >>> $ ps ax | grep beam.smp # Get the pid of couchdb >>> $ gdb >>> (gdb) attach $pid # Where $pid was just found with ps. Might >>> throw up an access prompt >>> (gdb) continue >>> # At this point, run the command that makes couchdb reboot in a >>> # different console. If it happens you should see Gdb notice the >>> # error. Then the following: >>> (gdb) t a a bt >>> >>> And that should spew out a bunch of stack traces. If you can get that >>> we should be able to fairly specifically narrow down the issue.
