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 >
