On 05/26/2011 10:39 PM, Boivin, Peter wrote: > I may be missing somethng, so I hope someone can assist me. I looked > through the documentation on starting and stopping a daemon. I see how > I can stop a daemon remotely (sfStopDaemon<REMOTEHOST>). How do you > start a daemon remotely? I have started my daemon by logging into the > system and starting it locally
on linux we just install the daemon RPM, which sets up the init.d scripts to start and stop SF automatically. > Sometimes it gets in a bad state. When > I am running smartfrog from another server, I would like to be able to > stop and restart the remote daemon to get it into a good state. I have > not seen yet how to do that. We don't have an explicit "log in and start SF" process, because there isn't a daemon there -it's a bit of a vicious cycle. We have hit a similar problem bringing up hosted VMs where the VM boot process actually installs the SF daemon from the RPMS, and starts it, and the remote code needs to block for that to happen, then deploy something. The way this is sone is in the code NodeDeploymentOverSSH - spin until the hostname resolves - spin until port 22 is open - spin until `which sfStart` works - spin until sfStart works the code: http://smartfrog.svn.sourceforge.net/viewvc/smartfrog/trunk/core/components/cloudfarmer/src/org/smartfrog/services/cloudfarmer/server/deployment/NodeDeploymentOverSSH.java?revision=8466&view=markup The nice thing about this is that you don't open any of the ports other than port 22 and whatever application you want to run; nobody can deploy remotely to your daemon. It also works over long-haul networks and handles delays in VM deployment reasonably well, depending on the timeout options. But in the world of VMs, the way to react to any problem in the VM, including sfDaemons not responding, is kill the VM and create a new one. Harsh but predictable. If you are having problems with the sfDaemon getting into a bad state 1. if it's our code, file bugreps: http://jira.smartfrog.org/jira/secure/Dashboard.jspa on linux, a kill -QUIT will get a stack trace of everything to paste in. 2. try starting all your applications in child processes, by setting the sfProcessName attribute of the component you are deploying: appserver extends AppServer { sfProcessName "AppServerSubProc"; }; Once you that the component and its children will get deployed into a new SF process (unless they change their process name) -the processes ping each other for health; if the child doesn't get pinged by its parent, eventually it times out and undeploys its components then terminates -the parent process can detect failure of a child, and depending on the policy of the parent process, choose how to react. There are various parent components in org.smartfrog.sfcore.workflow.combinators that handle failures differently (retry, don't care, etc). -Sometimes (Jetty Startup related), I've turned down the ping frequency: sfLivenessFactor 500; The process name you choose becomes an attribute of the root daemon, so don't give it the same name as anything else you deploy, life gets confusuing. You can deploy different trees of components into the same subprocess, just use the same name. -Steve ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Smartfrog-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/smartfrog-users
