Want to monitor process..

[Stephen]

Peter Hansen <peter at engcorp.com> wrote in message 
> > > Yikes!  "Crash"?  Do you really mean they crash the Python interpreter,
> > > or do you mean they exit with an exception?
> > 
> > Sorry, I guess I mean "exit with an exception" though to be honest, I
> > still don't know because I haven't been able to run the programs
> > interactively during a 'crash'.  
> 
> I'm not sure what the interactive thing would add, since the
> interpreter will already print exception tracebacks to the console
> whenever your program exits exceptionally.  If you aren't seeing
> a traceback, maybe you aren't really exiting with an exception.

Sorry, I should have explained that the reason I don't see the output
is that I run the programs in the background since I log into the
servers from remote and don't want the programs exiting when I log
out.


> > > If the latter, just wrap the highest level code with a try/finally
> > > or try/except and put code in to ensure the child processes are
> > > properly terminated.  Simple, clean, safe.
> > 
> > Will do.  I didn't want to put try/except/finally at the highest level
> > of code yet since we're actually in Beta and I want to know when my
> > server encounters a problem.  
> 
> No problem, just put a "raise" statement as the final statement in
> the exception handling block (when using try/except only) and you'll
> still propagate the exception up and right out of the interpreter
> so it prints a traceback to the console.

Good idea, this is something that I think I should employ for all code
in future.  When developing applications, I usually have exceptions
raised at the lowest level of code (eg. the module/class level) but
then as I start building the higher levels of code, the lower levels
get lost ('swallowed') as opposed to propagated up. Damn, wish that
had occured to me earlier.

>  In the try/finally case,
> however, you'll still get the traceback if an exception *did* 
> occur, because the interception is only a temporary one.  After the
> finally code executes, exception processing continues on.
>
> I think you might focus on the lack of a traceback.  You should
> always see one if you aren't explicitly swallowing the exception.
> (Note, a few standard modules such as the SocketServer and such
> will internally swallow exceptions in the server threads by default.)

I've been logged in and watching the console for several hours and I
am getting a traceback when errors occur ~ the difficulty I had before
was imposed by running to the background, which I've just seen in the
link below (http://cr.yp.to/daemontools/faq/create.html#why) is
apparently not good software design.

.................................

> From: Greg Green (gregory.p.green at boeing.com)
> Subject: Re: Want to monitor process.. 
> Newsgroups: comp.lang.python
> View this article only 
> Date: 2002-03-01 12:35:56 PST 
 > 
> 
> If you are using a unix OS, I would suggest using daemontools 
> from Bernstein. It has a set of tools for supervising a process. 
> I use it all of the time for these sorts of problems.

Excellent! This looks like just the ticket. I've actually employed it
in the past with Bernstein's Qmail but never truly understood the
importance of it. Now that I've read the minimalist documentation, I
think this is going to become an important addition to my toolbox.

Thank you, gentlemen, thank you.

Stephen.