couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nestor Urquiza <>
Subject Re: Running couchdb remotely (from an interactive shell)
Date Wed, 12 Dec 2012 17:30:24 GMT
Hi Shane,

CFEngine is doing the magic behind scenes. Try it please with:
$ ssh -t remoteserver sudo /etc/init.d/couchdb restart

Once the ssh command finishes couchdb dies.

I am starting couchdb just with the command above. It works from
command line when I am logged in the server but it fails when the
command is sent over ssh as with the command above.

Those options you refer to are interesting and might be a thing to
look at, I will try them and see how it goes. And yet I will need to
put them inside the current script or build a wrapper so the original
question will still remain: If it makes sense to modify the restart
script so it works from a remote execution via an interactive shell

BTW I need to use option -t as I need to interact with the remote box.
We do not want to send command by command but rather execute recipes
remotely from pure bash scripts.

- Nestor

On Wed, Dec 12, 2012 at 10:15 AM, Shane McEwan
<> wrote:
> I've restarted CouchDB using the supplied init.d script via ssh and also
> automatically with CFEngine many, many times and I've never had a problem
> with it killing the couchdb process when I logout.
> The nohup command disconnects a process from the terminal's stardard input,
> error and output file descriptors. I haven't had to use nohup since back
> when I used have a dial-up modem directly attached to a serial port on my
> servers.
> Are you starting couchdb with the '-o' and '-e' options? Maybe couchdb will
> disconnect STDOUT and STDERR for you and, thus, shouldn't need nohup.
> On 12/12/12 14:51, Nestor Urquiza wrote:
>> Hi Robert,
>> For maintenance purposes you might want to remotely restart couchdb.
>> For example you remotely install couchdb and after that you remotely
>> harden it (changing configuration files) which demands a restart.
>> We prefer to maintain the servers remotely rather than login into them
>> and manually execute commands. We script the commands for absolutely
>> everything, from building the whole server to patching it to changing
>> configuration etc.
>> With the same recipe we guarantee not relying on memory or going
>> manually through steps. The steps are in scripts.
>> BTW we use Plain Old Bash (POB) recipes with the help of Remoto-IT, a
>> simple and open source script based on expect and to remotely run
>> scripts in a server.
>> The init.d script as I said will die as it is attached to the console
>> session if you are running it from ssh. The nohup command can be used
>> like screen can be used as well (like mentioned in this thread).
>> I believe in these days where automation is key, couchdb should
>> support be run from a remote ssh interactive session. That is what my
>> change (using nohup) allows. I am wondering if it makes sense to
>> include the change even if it demands a configure or *.ini option.
>> Right now we are just storing the modified script on svn and patching
>> the original from POB recipes, it works but I just want to make sure
>> this is not such a need that makes it reasonable to have it as a
>> feature request for future releases of couchdb.
>> Thanks!
>> - Nestor
>> On Wed, Dec 12, 2012 at 8:59 AM, Robert Newson <> wrote:
>>> CouchDB includes a script to launch it as a daemon, a standard init.d
>>> script. I'm confused why you'd ssh to a machine, run couchdb in the
>>> foreground, and log off.
>>> On 12 December 2012 13:34, Wayne Conrad <> wrote:
>>>> On 12/11/2012 11:53 AM, Nestor Urquiza wrote:
>>>>> As other users have asked in the past to this list couchdb will not
>>>>> run from a remote interactive shell but rather it will be killed when
>>>>> the ssh session terminates. The command nohup can help with that. Here
>>>>> is what I did (which works OK):
>>>> Terminal multiplexors like screen and tmux are very good for "I want to
>>>> start a non-daemon, disconnect, and come back later to see what
>>>> happened."
>>>> Here's how it works with screen:
>>>> log on
>>>> $ screen
>>>> $ (enter log running command)
>>>> type control-a d to detach the screen session
>>>> log off
>>>> later...
>>>> log into the remote system
>>>> $ screen -r
>>>> and you'll be back in your long running program's term, including any
>>>> output
>>>> the program printed while you were gone.
>>>> Best Regards,
>>>> Wayne Conrad

View raw message