Hi Nestor, The ssh command you showed should create a couchdb process completely daemonized and immune to the exit of your shell, can you file a ticket at https://issues.apache.org/jira/browse/CouchDB please?
B. On 12 December 2012 17:30, Nestor Urquiza <[email protected]> wrote: > 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 > command. > > 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. > > Thanks, > - Nestor > > On Wed, Dec 12, 2012 at 10:15 AM, Shane McEwan > <[email protected]> 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 <[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
