Kevin, There are some options discussed here: http://stackoverflow.com/questions/285015/linux-prevent-a-background-process-from-being-stopped-after-closing-ssh-client
For a quick development test situation, you might try GNU Screen, though I doubt this is a good production solution. Best regards, Melissa ----- Dr. Melissa Rice, PhD Full Moon Technical Solutions, LLC 14202 60th Ave, NW Stanwood, WA 98292-4808 email: mailto:[email protected] phone: 360-654-0709 cell: 425-923-7713 Tuesday, May 3, 2011, 11:48:48 PM, Kevin LaTona <[email protected]> wrote: KL> Hi Andrew, KL> Maybe this will help better explain what I am doing here. KL> Once I have pinged a web service server and know it is down. KL> I will make this call ------ KL> ssh [email protected] nohup python /ws/server.py & exit KL> This calls and boots up the Python script okay. KL> As you can see right now I like to keep things simple and lean. KL> I've never used the nohup call before. KL> But it sounded like it should do the trick. KL> As I mentioned it runs for a good long while but then dies again for KL> no apparent reason. KL> When I remote in via a screen share to boot the Python script it runs KL> just fine. KL> This a test and is using Python's simple HHTP server for now. KL> so I know no running code within the script is causing it to crash. KL> It appears to just decide to shut down after a few hours while sitting KL> idle. KL> I was hoping maybe some one on the list might have another way to SSH KL> in to re / boot a Python Script idea? KL> -Kevin KL> On May 03, 2011, at 8:11 PM, Andrew Beyer wrote: >> On Tue, May 3, 2011 at 7:13 PM, Kevin LaTona <[email protected]> >> wrote: >> I think it might have something to do with the SSH call that is >> creating a headless / background process. >> I'm not sure what you mean by that...ssh isn't responsible for >> creating a long-lived process. Standard unix procedure is to have >> your process either get launched from inetd (or some similar service >> controller), or daemonize yourself. Are you actually detaching from >> your parents and the controlling terminal, or just running as a >> background process (bash '&')? The latter isn't sufficient to >> outlive the controlling (psuedo)terminal. >> Check out: >> http://code.activestate.com/recipes/278731-creating-a-daemon-the-python-way/ >> for the code necessary to do the whole detaching jig according to >> the rules. (many of which may be optional or unnecessary in some >> cases, but should be followed for portability and consistency.)
