Fixing one kind of couchDB silent failure

Searching around for issues that may arise when hosting your own instance of couchDB can be downright frightening. There are a fair number of posts on blogs and on Stack Overflow that have no solution, the community or the poster having given up as no reason can be found as to why couchDB is not functioning properly. I ran into this situation recently and was very concerned as what I was seeing seemed eerily similar to the situation a lot of others simply threw in the towel.

But I love a challenge, and also in this case I couldn’t refactor a production service due to couchDB issues. So I (figuratively) rolled up my sleeves and dug in. And dug further. And further still. I even revisited the recommended steps for installation but my particular issue was not solved with this document.

I kept going until finally I got back what I was hoping from the server:

[usr@service-monkey ~]# curl

The silent failure, as I am calling it, occurs when the environment has couchDB properly installed and the service running, but it is not reachable via the command line or via the appropriate port. This can be confirmed by either

[usr@service-monkey ~]# ps aux | grep couch
[usr@service-monkey ~]# ps aux | grep heart

Either will suffice to check if the service is running. The first command returns every running process related to couchDB, while the second command is truly meant to target the erlang beam.smb file in case it does not come up when running the first command.

Before implementing the solution to the silent failure problem the following command would return empty and look something like:

[usr@service-monkey ~]# curl

As you can see from this representation we are not getting back anything from the service, even though we know that both couchDB and erlang were running properly in our case. So, what did I do differently that others may not have managed to do? And is this a universal problem that occurs when self-hosting couchDB?

The solution in my case, and I suspect in some other cases, has to do with the version of the couchDB library that erlang has being out of sync with the version of couchDB. Replacing this with a matching library and restarting the couchDB service made it reachable and function properly. It looks like when erlang was updated it replaced the version of the couchDB library the server needed.

Within my CentOS environment checking the version of library is achieved by looking in the appropriate lib folder:

[usr@service-monkey ~]# ls -alh /usr/lib64/erlang/lib/ | grep couch
drwxr-xr-x 5 root root 4.0K Feb 17 2013 couch-0.11.0

Since the version of couchDB installed on the server is 1.4.0 the library here is a bit old. My most likely reason for this is that the package manager’s version of the library is older than my installation, and updating erlang brought about this problem.

Once I corrected the erlang couchDB library to the appropriate version the problem was addressed.

Hopefully my posting this will prompt others that may come across this situation in the future to consider checking into this since to date I have not seen any other mention to this being a potential solution for this silent failure.

Leave a Comment