Hi Melissa,
Thanks... I think this where I found the nohup call idea originally.
I'll read it again to see if I missed something.
-Kevin
On May 04, 2011, at 12:03 AM, Melissa Rice wrote:
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.)
