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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>
