Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: couchdb returning empty response
From: Robert Newson <rnewson@apache.org>
In-Reply-To: 
 <CAGxYWpae6_YdaTzgQwTxRGnDrdKxm8ZJwj5AQSdLyDN_BBWHag@mail.gmail.com>
Date: Fri, 17 Aug 2012 09:33:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE6DDCBB-14D7-4692-8383-59463D33F3CC@apache.org>
References: 
 <CAGxYWpZh_pNz3gH-WW544M3h8+=nLFYQo8vipAQBOpaN2CJJGQ@mail.gmail.com>
 <CAJ_m3YAMRFjVrCROUNK05hTqXtCb7ieZ3ED5D9-G6RF+G+v7Eg@mail.gmail.com>
 <CAGxYWpae6_YdaTzgQwTxRGnDrdKxm8ZJwj5AQSdLyDN_BBWHag@mail.gmail.com>
To: user@couchdb.apache.org


I've seen couchdb start despite the eacces errors before and tracked it =
down to the current working directory setting. It seems that the cwd is =
searched first, and then erlang looks elsewhere. So, if our startup =
script doesn't change it to somewhere that the couchdb user can read, =
you get spurious eacces errors.

Don't ask me how I know this.

B.

On 16 Aug 2012, at 20:19, Tim Tisdall wrote:

> Paul, did you ever solve the eaccess problem you had described here:
> =
http://mail-archives.apache.org/mod_mbox/couchdb-user/201106.mbox/%3C4E0B3=
04F.5080109@lymegreen.co.uk%3E
>  I found that post from doing Google searches for my issue.
>=20
> On Tue, Aug 14, 2012 at 11:41 PM, Paul Davis
> <paul.joseph.davis@gmail.com> wrote:
>> On Tue, Aug 14, 2012 at 9:38 PM, Tim Tisdall <tisdall@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...
>>>=20
>>> I stopped using fsockopen() in PHP and am using curl now to =
hopefully
>>> be able to see more debugging info.
>>>=20
>>> I get an empty response when sending a POST to _bulk_docs.  =46rom =
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)
>>>=20
>>>=20
>>> [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/
>>>=20
>>>=20
>>> In my code logs I have the following by running curl in verbose =
mode:
>>>=20
>>> * 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
>>>=20
>>> * Empty reply from server
>>> * Connection #0 to host localhost left intact
>>> curl error: 52 : Empty reply from server
>>>=20
>>>=20
>>>=20
>>> 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.
>>>=20
>>> -Tim
>>=20
>> If you have a request that triggers this, a good way to catch it is =
like such:
>>=20
>>    $ /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
>>=20
>> 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.