Re: [Zope-dev] [PATCH] Forking daemon in debug mode, and new start scripts
[Sorry about the broken thread] On January 20, Guido van Rossum wrote:
You seem to forget that in debugging mode there are other things that happen (or not) besides logging.
Ah, the infamous Zope side-effect, aka "other cool stuff". :-) Thanks for the heads-up.
And you can log to stderr (that's what I use 99% of the time).
But this means I can't really write a start script that works (or makes sense) with debug mode both on and off. Redirecting stderr to EVENT_LOG_FILE doesn't really make sense if we're detaching, and is ugly, etc.. I could write some shell polava to figure it out, but:
Maybe the "debug" flag is misnamed? All it really means is "don't detach".
Yes. I would much prefer an explicit flag for each, because I run a number of dev Zopes on a number of boxes to which I only have ssh access, and I don't want to have to remember to play games with my stdio, or restart Zope if I restart screen, etc. Speaking of the (side-)effects of debug mode, what exactly are they? Is it just the automatic re-loading of DTMLFiles and PageTemplates from disk? a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
On Tue, 2003-01-21 at 18:45, Adrian van den Dries wrote:
But this means I can't really write a start script that works (or makes sense) with debug mode both on and off. Redirecting stderr to EVENT_LOG_FILE doesn't really make sense if we're detaching, and is ugly, etc.. I could write some shell polava to figure it out, but:
FWIW, I often use: z2.py -Z0 STUPID_LOG_FILE= ... which prevents Zope from detaching from the terminal but doesn't imply debug mode. This may only work on recent checkouts, the semantics of -Z have changed recently.
Maybe the "debug" flag is misnamed? All it really means is "don't detach".
It unfortunately means lots of things, all of which are implicitly twisted together in a huge mess, much of it even predating Zope's open source release.
Yes. I would much prefer an explicit flag for each, because I run a number of dev Zopes on a number of boxes to which I only have ssh access, and I don't want to have to remember to play games with my stdio, or restart Zope if I restart screen, etc.
Yup.
Speaking of the (side-)effects of debug mode, what exactly are they? Is it just the automatic re-loading of DTMLFiles and PageTemplates from disk?
It's that... and, unfortunately, god knows what else. To find out for sure, we'd need to audit the codebase (looking mostly for Z_DEBUG_MODE and __debug__). I'd like to address these problems for Zope 2.7, but I doubt it's going to be possible in the short term. - C
On January 21, Chris McDonough wrote:
It unfortunately means lots of things, all of which are implicitly twisted together in a huge mess
I wasn't going to say it. ;-)
It's that... and, unfortunately, god knows what else. To find out for sure, we'd need to audit the codebase (looking mostly for Z_DEBUG_MODE and __debug__).
I'd like to address these problems for Zope 2.7, but I doubt it's going to be possible in the short term.
Hrm, a refactor, eh? adriand@pita:~/Zope-2.6.0b1-src$ egrep -Iir 'principia|bobo' * | wc -l 345 ;-) a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
On Tue, Jan 21, 2003 at 07:26:11PM -0500, Chris McDonough wrote:
z2.py -Z0 STUPID_LOG_FILE=
... which prevents Zope from detaching from the terminal but doesn't imply debug mode. This may only work on recent checkouts, the semantics of -Z have changed recently.
Interesting! In 2.6.0 the -Z flag is documented thus: -Z 0 or 1 UNIX only! This option is ignored on Windows. This option controls whether a management process will be created that restarts Zope after a shutdown or crash. If the argument to -Z is non-null (e.g. "-Z1" or "-Zyes"), a management process will be used. If the argument to -Z is "-", or "0", (e.g. "-Z-" or "-Z0"), a management process will not be used. On UNIX, the default behavior is to create a separate management process (e.g. -Z1) if the -Z option is not specified. (Note: the -Z option in Zopes before Zope 2.6 used to be used to specify a pidfile name for the management process. This pidfile no longer exists).
Speaking of the (side-)effects of debug mode, what exactly are they? Is it just the automatic re-loading of DTMLFiles and PageTemplates from disk?
It's that... and, unfortunately, god knows what else. To find out for sure, we'd need to audit the codebase (looking mostly for Z_DEBUG_MODE and __debug__).
at least in < 2.6 it also toggled whether tracebacks were displayed openly (debug mode) or embedded in an html comment.
I'd like to address these problems for Zope 2.7, but I doubt it's going to be possible in the short term.
What he said. :( -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE TONGUE! (courtesy of isometric.spaceninja.com)
But this means I can't really write a start script that works (or makes sense) with debug mode both on and off.
I don't think that's a valid use case anyway. Remember, "debug" mode really means "don't daemonize" and nothing more. This for use by a developer who wants to see possible exceptions, print statements and other stuff that goes to stdout/stderr.
Yes. I would much prefer an explicit flag for each, because I run a number of dev Zopes on a number of boxes to which I only have ssh access, and I don't want to have to remember to play games with my stdio, or restart Zope if I restart screen, etc.
Speaking of the (side-)effects of debug mode, what exactly are they? Is it just the automatic re-loading of DTMLFiles and PageTemplates from disk?
I've tried to explain already -- debug mode for ZEO *only* determines whether the ZEO server goes into daemon mode or not. There may be a Zope debug mode, but it's not related (even if it uses the same envariable). --Guido van Rossum (home page: http://www.python.org/~guido/)
[OK, I've subscribed now] On January 21, Guido van Rossum wrote:
There may be a Zope debug mode, but it's not related (even if it uses the same envariable).
I'm sorry, I'm talking about Zope's debug mode. a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
On January 21, Guido van Rossum wrote:
There may be a Zope debug mode, but it's not related (even if it uses the same envariable).
I'm sorry, I'm talking about Zope's debug mode.
Eh? This started with your suggesting a change to ZEO/start.py, to which I objected. Oh well. What a waste of time. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, Jan 21, 2003 at 08:07:01PM -0500, Guido van Rossum wrote:
On January 21, Guido van Rossum wrote:
There may be a Zope debug mode, but it's not related (even if it uses the same envariable).
I'm sorry, I'm talking about Zope's debug mode.
Eh? This started with your suggesting a change to ZEO/start.py, to which I objected.
Oh well. What a waste of time.
Now I'm lost. He posted a patch to lib/python/zdaemon/Daemon.py. Nobody said anything about ZEO/start.py. -- Paul Winkler http://www.slinkp.com
Eh? This started with your suggesting a change to ZEO/start.py, to which I objected.
Oh well. What a waste of time.
Now I'm lost. He posted a patch to lib/python/zdaemon/Daemon.py. Nobody said anything about ZEO/start.py.
You're right. :-( I know that file from the context of ZODB. But it is also used by Zope. I'm sorry for the confusion. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, Jan 21, 2003 at 09:10:50PM -0500, Guido van Rossum wrote:
Eh? This started with your suggesting a change to ZEO/start.py, to which I objected.
Oh well. What a waste of time.
Now I'm lost. He posted a patch to lib/python/zdaemon/Daemon.py. Nobody said anything about ZEO/start.py.
You're right. :-(
okay, NP... just trying to make sure i understood the discussion. a summary, AFAICT: everybody agrees that splitting up the many things in Zope toggled by debug mode would be a good thing, but nobody has time to do it. :( -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE TALKING ICE! (courtesy of isometric.spaceninja.com)
a summary, AFAICT: everybody agrees that splitting up the many things in Zope toggled by debug mode would be a good thing, but nobody has time to do it. :(
Actually, on the chrism-installer-branch, we're doing something about it, and we're getting closer. Most likely, Zope 2.7 will use zdrun.py from the ZODB 3.2 CVS for process management. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tuesday 21 January 2003 06:45 pm, Adrian van den Dries wrote:
[Sorry about the broken thread]
On January 20, Guido van Rossum wrote:
You seem to forget that in debugging mode there are other things that happen (or not) besides logging.
Ah, the infamous Zope side-effect, aka "other cool stuff". :-) Thanks for the heads-up.
And you can log to stderr (that's what I use 99% of the time).
But this means I can't really write a start script that works (or makes sense) with debug mode both on and off. Redirecting stderr to EVENT_LOG_FILE doesn't really make sense if we're detaching, and is ugly, etc.. I could write some shell polava to figure it out, but:
Maybe the "debug" flag is misnamed? All it really means is "don't detach".
Yes. I would much prefer an explicit flag for each, because I run a number of dev Zopes on a number of boxes to which I only have ssh access, and I don't want to have to remember to play games with my stdio, or restart Zope if I restart screen, etc.
Speaking of the (side-)effects of debug mode, what exactly are they? Is it just the automatic re-loading of DTMLFiles and PageTemplates from disk?
There's a lot of code that gets enabled when the debug (also known as development) mode gets turned on. Most of it involves auto-refreshing things from the file system, but there are many other things. Zope generally runs *much* slower in "debug" mode then in production mode also. -Casey
participants (5)
-
Adrian van den Dries -
Casey Duncan -
Chris McDonough -
Guido van Rossum -
Paul Winkler