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 <[email protected]> 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 <[email protected]> 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
