couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Rupp <>
Subject Re: installing couchdb 1.0.1 will not override .010 ubuntu 10.04 install
Date Sun, 29 Aug 2010 17:20:41 GMT
I'm going to take a shot in the dark and guess it's either

  - incorrect file/folder permissions on couchdb files
  - older couchdb currently running and using port

What's the output of a

	ps -ef |grep couch

That would eliminate the 2nd guess.

If you installed couchdb via an ubuntu package, that's what probably put 
files in /etc. If you built it from source and everything is stashed in 
/opt/couchdb-1.0.1, then I'd imagine there is a local.ini in the etc 
subdirectory, or some other subdirectory, of that.

I'm assuming that you didn't remove the previous apt package yet either, 
or else you have '.' in your path, because ./couchdb -c would be the 
command I would expect (including the ./) otherwise I'm guessing you're 
calling the ubuntu supplied one which would explain the configuration 
paths that are listed.

So a couple things

- check whether couch is running with ps and grep

- find whether or not there is a local.ini in a sub directory of 
/opt/couchdb-1.0.1 and if there is, check to see what the port and bind 
address are set to. Also set the log level to debug and check the path 
to the database files (database_dir and view_index_dir) and make sure 
the files in those directories are owned by the couch user.

   that would eliminate the first guess

- whats the output of /opt/couchdb-1.0.1/bin/couchdb -c ? My guess is a 
different path from the files in /etc

If after permissions and port checks it still doesn't run, run couch 
with the debug log level and send the output of relevant log entries in 
the couchdb log file.

If it's not specified, you can set the log file in your local.ini


level = debug
file = /opt/couchdb-1.0.1/var/log/couchdb/couch.log

And if that doesn't turn on any light-bulbs in our heads, the next thing 
I'd do is strace the process and see if the output reveals any other clues.

Topics on this page

Seem to suggest permissions though.


On 08/29/2010 11:50 AM, wrote:
> init terminating in do_boot",{{badmatch

View raw message