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 tisdall@gmail.com designates
 209.85.215.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <EB6D0921-4540-4DAC-B463-7DA2884019C1@apache.org>
References: 
 <CAGxYWpYK26aBUC+K1DLCvoRPY54sYH8z70=wQY5zxtWbXHbFxg@mail.gmail.com>
	<CALpjNynO08eHdBj8U==QSM4vOCg6ESFCTV6sCmxs31T=HC_ogg@mail.gmail.com>
	<CAGxYWpZU8VUKE7_inxoK7m1ytxWufD729Ys1LJTgDKrsmU2rxg@mail.gmail.com>
	<CAGxYWpbwP1Kmj3-2TUe2eWxQtf1x1tp=zQjBWG4iXtd6SNkH-w@mail.gmail.com>
	<EB6D0921-4540-4DAC-B463-7DA2884019C1@apache.org>
Date: Tue, 7 Aug 2012 14:11:53 -0400
Message-ID: 
 <CAGxYWpaUbXQApAMqccZ747huGTR5AQcF6+eCDmik_y-e2TS7VQ@mail.gmail.com>
Subject: Re: more refused connections
From: Tim Tisdall <tisdall@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I have /var/lib/couchdb as the home directory for the couchdb user and
it's set to be rwx by that user.  I'm using the init script I think I
found on the wiki (it's been months now).  I'll try adding a 'cd
~couchdb' in there, but I don't think that will help (but can't hurt
either).

I'm currently have an "admin party", so I don't know if
couch_httpd_auth.beam is even needed in that circumstance.

I had two crashes today that said "OS process timed out."...  what
could cause that?

On Tue, Aug 7, 2012 at 10:11 AM, Robert Newson <rnewson@apache.org> wrote:
>
> This might come down to how the code loader searches for beam files. The =
current working directory seems to be searched first, which might not be re=
adable by the couchdb user (depending on how you launched couchdb). If you =
get eacces to couch_httpd_auth.beam but can still login, then we must have =
found a readable copy somewhere. I've seen this happen in bigcouch clusters=
 recently, and tracked it (somewhat laboriously) to the bigcouch startup sc=
ript. Adding a simple 'cd ~bigcouch' was the fix there.
>
> B.
>
> On 7 Aug 2012, at 14:59, Tim Tisdall wrote:
>
>> Yeah, the problem definitely seems to be the server restarting.  Any
>> idea why couchdb would be having trouble accessing those files?  I
>> found an older post about people having a similar problem on EC2,
>> though I'm using a different VPS solution then that.  Everything runs
>> fine until the log starts showing those "eacces" errors and then the
>> server seems to restart and continue running with no problem.  Ideas?
>>
>> -Tim
>>
>> On Mon, Aug 6, 2012 at 5:41 PM, Tim Tisdall <tisdall@gmail.com> wrote:
>>> I can confirm that the server is running before and directly after the
>>> error occurs.  I think I've seen where compaction or view creations
>>> have suddenly stopped as if the server restarted.  Does CouchDB
>>> automatically restart under certain circumstances?  Maybe it's in the
>>> middle of restarting when I get the refused connection.
>>>
>>> I'm not using a library, but pretty much the same code as what's in
>>> the wiki...   http://wiki.apache.org/couchdb/Getting_started_with_PHP
>>> The CouchSimple class.  The fsockopen() method is what throws the
>>> error.
>>>
>>> I'm using 1.2.0
>>>
>>> And unfortunately I can't reliably replicate the problem.  I was
>>> having it occur quite a bit a few months ago, but then it went away.
>>> According to my logs, it seems that immediately before the refused
>>> connection I get an empty response (I got an error when I try to parse
>>> the response as JSON and I saw that it was empty).  ....  I just
>>> checked my couch.log and see this:
>>>
>>> [Mon, 06 Aug 2012 19:53:02 GMT] [error] [<0.20.0>] {error_report,<0.9.0=
>,
>>>                                 {<0.20.0>,std_error,
>>>                                  "File operation error: eacces.
>>> Target: ./couch_httpd_oauth.beam. Function: get_file. Process:
>>> code_server."}}
>>> [Mon, 06 Aug 2012 19:53:02 GMT] [error] [<0.20.0>] {error_report,<0.9.0=
>,
>>>                                 {<0.20.0>,std_error,
>>>                                  "File operation error: eacces.
>>> Target: ./oauth_uri.beam. Function: get_file. Process: code_server."}}
>>> [Mon, 06 Aug 2012 19:53:02 GMT] [error] [<0.20.0>] {error_report,<0.9.0=
>,
>>>                                 {<0.20.0>,std_error,
>>>                                  "File operation error: eacces.
>>> Target: ./couch_httpd_auth.beam. Function: get_file. Process:
>>> code_server."}}
>>> [Mon, 06 Aug 2012 19:53:02 GMT] [error] [<0.20.0>] {error_report,<0.9.0=
>,
>>>                                 {<0.20.0>,std_error,
>>>                                  "File operation error: eacces.
>>> Target: ./couch_httpd_db.beam. Function: get_file. Process:
>>> code_server."}}
>>>
>>>
>>> I think I have all the permissions correct as far as I can see...  For
>>> example the last file, couch_httpd_db.beam, has read permissions to
>>> all.
>>>
>>>
>>> On Mon, Aug 6, 2012 at 12:31 PM, Sam Bisbee <sam@sbisbee.com> wrote:
>>>> Hi Tim,
>>>>
>>>> A few questions to help with the debugging...
>>>>
>>>>  - Can you confirm that CouchDB is actually running when you see this =
problem?
>>>>
>>>>  - How are you connecting to CouchDB from PHP? Are you using a library=
?
>>>>
>>>>  - What version of CouchDB are you using?
>>>>
>>>>  - Can you provide a reliable set of steps to reproduce this problem?
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> Sam Bisbee
>>>>
>>>> On Sun, Aug 5, 2012 at 2:26 PM, Tim Tisdall <tisdall@gmail.com> wrote:
>>>>> Well, I've had this problem before, but I still have no idea what
>>>>> caused it then, why it went away, or why it's back again.  :S
>>>>>
>>>>> "PHP Warning:  fsockopen(): unable to connect to localhost:5984
>>>>> (Connection refused)"
>>>>>
>>>>> After making several bulk updates of about 100 documents each, I then
>>>>> get this warning.  That means that the same code executed fine severa=
l
>>>>> times and then suddenly gave me a "connection refused".  Why would
>>>>> CouchDB be refusing connections?
>>>>>
>>>>> I also occasionally get back invalid JSON responses from CouchDB
>>>>> either because the content returned is truncated or completely
>>>>> missing.  I'm not sure if the 2 issues are related.
>>>>>
>>>>> Anyone else have problems like this with PHP?
>>>>>
>>>>> -Tim
>