Yes, sometimes such an error can be a really pain. The amp char does set
the application to run in the background, but it doesn't detach it from
the session. So, once the session is closed, the application is
terminated as well. If you really want an application to run in the
detached mode, you should use nohup or screen. I prefer nohup (no hangup).
In the case of CouchDB, yes, it has the option -b as a substitute for nohup.
You are welcome even if I couldn't do too much to help you.
Cheers,
CGS
On 10/26/2011 03:20 PM, Ron Dyck wrote:
Thank-you CGS for your help. Much of the information you've provided
below is very good. Yesterday evening I think I found the solution.
I've installed couchdb with iriscouch/build-couchdb from
https://github.com/iriscouch/build-couchdb
This install uses a different type of start-up script that does not by
default run in the background. I start the script with "./bin/couchdb
&" However as I discovered, using '&' for this script does not really
allow it to run in the background, it requires the switch -b. When I
closed the terminal window, I was getting inconsistent connectivity.
It appears as though I've solved the problem now.
I really appreciate your help in helping me discover the problem.
Regards,
ron
On Wed, Oct 26, 2011 at 4:38 AM, CGS<[email protected]> wrote:
It seems stable and not that bad to raise the error you spoke of. But did
you encount the problem while this test was done?
As you can notice, I am trying blindly to determine if there is a problem in
your server network configuration. It may be that your server was set up
correctly and I am sending you to a wild goose chase. I apologize for that,
but error 111 speaks mostly about a problem in connecting to the server and
since you reported that there is nothing wrong in the CouchDB log nor in
your firewall, I do not know where exactly the problem may come from. If
anyone has a better idea how to debug this, please, by all means, override
my approach.
Try to put bind_address a dedicated address (e.g., 127.0.0.1 or
107.20.142.27) and restart CouchDB. That's because 0.0.0.0 is listening all
the bind addresses generally and if there is something wrong in one address
bind setup, that may cause problems (unlikely, but not impossible). So here
is what I propose:
1. Set your bind_address to 127.0.0.1 and check from the same machine curl
http://127.0.0.1:5984.
2. If it doesn't work, try change the port to 80 (if you don't have anything
else running on that port) and restart CouchDB as root. Check again, but do
not add port number to the address.
3. If you have something running on port 80, try curl http://127.0.0.1:80
(port number not necessary) and if it is working properly, stop your
application and follow point 2.
4. Try the same for 107.20.142.27.
5. If it is not working, then stop CouchDB, clear the log and start it
again. See if reports something wrong in accessing the configuration/log/pid
or any other file (it can be that the path toward one of those files is
broken - running as root overrides all the permissions, so, it shouldn't be
a matter of permissions).
6. If anyone has a better idea, please, disregard this post (as I said it
before).
If all these are not reporting anything wrong and still you get the same
problem, you may want to ask for the help of one of the system
administrators in charge of your server.
Cheers,
CGS
PS: If I will get any other idea, I will come back with a post.
