incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Tisdall <tisd...@gmail.com>
Subject Re: more refused connections
Date Tue, 07 Aug 2012 20:55:10 GMT
I did an upgrade of the spidermonkey package a few days ago but didn't
think I'd need to recompile couchdb so I didn't think much about it.
It's possible that there's something going wrong there, so I'll try
recompiling just to see if it helps at all.

Just to make sure I don't lose all my data...  "make install" knows to
leave the .couch files alone, right?  :)

-Tim

On Tue, Aug 7, 2012 at 2:11 PM, Tim Tisdall <tisdall@gmail.com> wrote:
> 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 readable 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 script. 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 several
>>>>>> 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
>>

Mime
View raw message