I just tried that now and restarted the server... It seems there's a erl_crash.dump in whatever directory I started the init.d script. The file also keeps expanding along with the STDERR and STDOUT files. stdout file says this over and over again: Apache CouchDB 1.2.0 (LogLevel=info) is starting. Error opening log file /var/log/couchdb/couch.log: permission denied{"init terminating in do_boot",{{badmatch,{error,{bad_return,{{couch_app,start,[normal,["/etc/couchdb/default.ini","/etc/couchdb/local.ini"]]},{'EXIT',{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1},{application_master,start_it_old,4}]}}}}}},[{couch,start,0},{init,start_it,1},{init,start_em,1}]}} I chown'ed the log file and now it seems to be responding to curl! Yeay! I'm pretty sure I ran the couchdb through the init.d script first, but I did run it directly so maybe it created the other files as root when I did that? On Fri, May 11, 2012 at 9:16 PM, Keith Gable wrote: > Did you chown -R? You want the files in the directory to also be owned by > couchdb:couchdb. > On May 11, 2012 8:13 PM, "Tim Tisdall" wrote: > > > Okay, I managed to figure out the problem with outputting STDERR, I had > > mistyped the path in /etc/default/couchdb. oops! So, now I can get a > > little more details on the problem... Here's what I get from STDOUT when > > running /etc/init.d/couchdb: > > > > ------------------------- > > {error_logger,{{2012,5,12},{0,17,27}},std_error,"File operation error: > > eacces. Target: .. Function: read_file_info. Proces > > s: code_server."} > > {error_logger,{{2012,5,12},{0,17,27}},std_error,"File operation error: > > eacces. Target: ./standard_error.beam. Function: ge > > t_file. Process: code_server."} > > {error_logger,{{2012,5,12},{0,17,27}},std_error,"File operation error: > > eacces. Target: ./supervisor_bridge.beam. Function: > > get_file. Process: code_server."} > > {error_logger,{{2012,5,12},{0,17,27}},std_error,"File operation error: > > eacces. Target: ./user_sup.beam. Function: get_file > > . Process: code_server."} > > {error_logger,{{2012,5,12},{0,17,27}},std_error,"File operation error: > > eacces. Target: ./user.beam. Function: get_file. Pr > > ocess: code_server."} > > {error_logger,{{2012,5,12},{0,17,27}},std_error,"File operation error: > > eacces. Target: ./kernel_config.beam. Function: get > > _file. Process: code_server."} > > {error_logger,{{2012,5,12},{0,17,27}},std_error,"File operation error: > > eacces. Target: ./queue.beam. Function: get_file. P > > rocess: code_server."} > > > > =ERROR REPORT==== 12-May-2012::00:17:27 === > > File operation error: eacces. Target: .. Function: read_file_info. > Process: > > code_server. > > > > =ERROR REPORT==== 12-May-2012::00:17:27 === > > File operation error: eacces. Target: ./standard_error.beam. Function: > > get_file. Process: code_server. > > > > =ERROR REPORT==== 12-May-2012::00:17:27 === > > File operation error: eacces. Target: ./supervisor_bridge.beam. Function: > > get_file. Process: code_server. > > > > =ERROR REPORT==== 12-May-2012::00:17:27 === > > File operation error: eacces. Target: ./user_sup.beam. Function: > get_file. > > Process: code_server. > > > > =ERROR REPORT==== 12-May-2012::00:17:27 === > > File operation error: eacces. Target: ./user.beam. Function: get_file. > > Process: code_server. > > > > =ERROR REPORT==== 12-May-2012::00:17:27 === > > File operation error: eacces. Target: ./kernel_config.beam. Function: > > get_file. Process: code_server. > > > > ------ SNIP ----------------- > > > > > > Here's something telling: > > =ERROR REPORT==== 12-May-2012::00:17:27 === > > file:path_eval([".","/var/lib/couchdb"],".erlang"): permission denied > > > > I've set /var/lib/couchdb to be owned and writable by the "couchdb" user, > > but the files being created in there all belong to root. > > > > Again, everything works fine if I run 'couchdb -b', but the init.d script > > results in this: > > > > # curl http://localhost:5984/ > > curl: (7) couldn't connect to host > > > > > > > > > > > > On Thu, May 10, 2012 at 10:58 PM, Tim Tisdall wrote: > > > > > Yes, I set r/w permission on those directories. > > > > > > On Thu, May 10, 2012 at 10:56 PM, Jim Klo wrote: > > > > > >> The init.d script runs suid. Does your CouchDB user have read and > write > > >> permissions to /var/{log,lib}/couchdb? > > >> > > >> - Jim > > >> > > >> Sent from my iPhone > > >> > > >> On May 10, 2012, at 11:46 AM, "Tim Tisdall" > wrote: > > >> > > >> > I've tried doing lots of Google searches for an answer to this, but > I > > >> > haven't been successful... > > >> > > > >> > I've installed Couchdb 1.2 from source on Debian 6. I configured it > > >> > with *--localstatedir=/var > > >> > --sysconfdir=/etc . Everything seems to be installed correctly.* > > >> > * > > >> > * > > >> > *If I run couchdb from the command prompt it seems to run correctly > > and > > >> I'm > > >> > able to hit the port with curl and get > > >> *{"couchdb":"Welcome","version":"1.2.0"} > > >> > successfully. If I run it as "couchdb -b" it also works properly. > > >> > > > >> > Now, the problem... if I try to run things using /etc/init.d/couchdb > > it > > >> > doesn't seem to work properly. I don't get any error messages but > the > > >> curl > > >> > request returns "couldn't connect to host". Also, there seems to be > a > > >> > process running under the couchdb user id, but it's not the same > > process > > >> > number as what's found in /var/run/couchdb/couchdb.pid. ps reports > it > > as > > >> > "/bin/sh -e /usr/local/bin/couchdb -a /etc/couchdb/default.ini -a > > >> > /etc/couchdb/local.ini -b -r 5 -p /var/run/couchdb/couchdb.pid -o > > >> /dev/null > > >> > -e /dev/null -R" but there's no response using curl. > > >> > > > >> > Anyone have any ideas how to track down the problem? I don't see any > > >> errors > > >> > in the logs. > > >> > > > >> > I've tried redirecting the STDERR to /dev/log/couchdb/stderr.log but > > get > > >> > the error "Starting database server: couchdbApache CouchDB needs > write > > >> > permission on the STDERR file: /dev/log/couchdb/stderr.log" despite > > >> giving > > >> > it full write permissions. > > >> > > > > > > > > >