Installing Products with Errors in Zope 2.7.4
Hi, I'm currently testing out Zope 2.7.4, and Zope's behaviour when installing new products seems to have changed from 2.6.4 (my previous version). Whenever I install a product with errors Zope crashes (ie. zoperun throws an exception, shows a traceback and stops, zopectl tries to restart Zope every few seconds). Zope 2.6.4 would start as usual, and show an error message in the Products screen. Is this the normal behaviour in 2.7.4? If so, why? Bert Vanderbauwhede
I'm currently testing out Zope 2.7.4, and Zope's behaviour when installing new products seems to have changed from 2.6.4 (my previous version). Whenever I install a product with errors Zope crashes (ie. zoperun throws an exception, shows a traceback and stops, zopectl tries to restart Zope every few seconds). Zope 2.6.4 would start as usual, and show an error message in the Products screen.
Is this the normal behaviour in 2.7.4? If so, why? I think it is done like that in order to avoid having references to broken products. However, if I'm not wrong, it has to be with the "debug-mode" directive of the zope.conf file, which is "on" by default. If you read about this option you will find:
"Errors in product initialization will cause startup to fail (instead of writing error messages to the event log file)." So you may turn it off if you want that behaviour back. Regards, Josef
Bert Vanderbauwhede wrote at 2005-3-8 14:08 +0100:
... Whenever I install a product with errors Zope crashes (ie. zoperun throws an exception, shows a traceback and stops, zopectl tries to restart Zope every few seconds). Zope 2.6.4 would start as usual, and show an error message in the Products screen.
Is this the normal behaviour in 2.7.4? If so, why?
I, too, would like to know that... In my view it is completely stupid! Especially, combined with the stupid logging behaviour during startup that causes error reports during this phase to be lost! It comes from "OFS.Application.install_products". In our version of Zope, I disabled this "feature": install_product(app, product_dir, product_name, meta_types, folder_permissions, # DM: don't! # we may want to be stricter in production mode # raise_exc=debug_mode, ) The comments above get rid of it. -- Dieter
On Tue, 8 Mar 2005 19:57:47 +0100, Dieter Maurer <dieter@handshake.de> wrote:
Bert Vanderbauwhede wrote at 2005-3-8 14:08 +0100:
... Whenever I install a product with errors Zope crashes (ie. zoperun throws an exception, shows a traceback and stops, zopectl tries to restart Zope every few seconds). Zope 2.6.4 would start as usual, and show an error message in the Products screen.
Is this the normal behaviour in 2.7.4? If so, why?
I, too, would like to know that... In my view it is completely stupid! Especially, combined with the stupid logging behaviour during startup that causes error reports during this phase to be lost!
Adding "debug-mode off" to the zope configuration file works. So it is related to the debug mode. But crashing without writing the details to the event log isn't what I would expect from a debug mode. Bert Vanderbauwhede...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bert Vanderbauwhede wrote: | On Tue, 8 Mar 2005 19:57:47 +0100, Dieter Maurer <dieter@handshake.de> wrote: | |>Bert Vanderbauwhede wrote at 2005-3-8 14:08 +0100: |> |>>... |>>Whenever I install |>>a product with errors Zope crashes (ie. zoperun throws an exception, shows a |>>traceback and stops, zopectl tries to restart Zope every few seconds). |>>Zope 2.6.4 |>>would start as usual, and show an error message in the Products screen. |>> |>>Is this the normal behaviour in 2.7.4? If so, why? |> |>I, too, would like to know that... |>In my view it is completely stupid! |>Especially, combined with the stupid logging behaviour |>during startup that causes error reports during this phase |>to be lost! | | | Adding "debug-mode off" to the zope configuration file works. So it is | related to the | debug mode. But crashing without writing the details to the event log | isn't what I would expect from a debug mode. That isn't what I see: when I try to start Zope for debugging ('debug-mode on' in zope.conf, running 'zopectl foreground') with a broken product, I see the traceback from the broken product on the console. In production mode, the startup code just logs the fact of the broken product and continues the startup. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCL2mJGqWXf00rNCgRAk/rAJ4ivigpGVWvdClpBe7bn3Tn6nMsCwCgj+Ta qv+rv9AKzr4HGSmaybm/hv4= =n/SU -----END PGP SIGNATURE-----
Tres Seaver wrote at 2005-3-9 16:24 -0500:
... But crashing without writing the details to the event log | isn't what I would expect from a debug mode.
That isn't what I see: when I try to start Zope for debugging ('debug-mode on' in zope.conf, running 'zopectl foreground') with a broken product, I see the traceback from the broken product on the console.
We usually start Zope with "bin/zopectl start" (because consoles are not garanteed to remain open). And then you see nothing, when there are problems during startup. -- Dieter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dieter Maurer wrote: | Tres Seaver wrote at 2005-3-9 16:24 -0500: | |>... |> But crashing without writing the details to the event log | isn't |> what I would expect from a debug mode. |> |> That isn't what I see: when I try to start Zope for debugging |> ('debug-mode on' in zope.conf, running 'zopectl foreground') with a |> broken product, I see the traceback from the broken product on the |> console. | | We usually start Zope with "bin/zopectl start" (because consoles are | not garanteed to remain open). And then you see nothing, when there | are problems during startup. When debugging a starup problem, I always start the appserver in the foreground, with debug-mode turned on; I then Ctrl-C to kill the foreground process (once it *does* start) and restart it in the background. The only glitch I see in this approach is that I think starting Zope in the foreground (via 'zopectl fg') should automatically turn on debug-mode; then I wouldn't need to edit zope.conf, and then re-edit it when done. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMKGNGqWXf00rNCgRAo72AJ9OE5GKFUL3nBfymAcyt0hzX8L+KACeMxQm PYTXEm+9jaTnarzXP/WFrUA= =ROiM -----END PGP SIGNATURE-----
On Thu, 2005-03-10 at 14:35, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dieter Maurer wrote: | Tres Seaver wrote at 2005-3-9 16:24 -0500: | |>... |> But crashing without writing the details to the event log | isn't |> what I would expect from a debug mode. |> |> That isn't what I see: when I try to start Zope for debugging |> ('debug-mode on' in zope.conf, running 'zopectl foreground') with a |> broken product, I see the traceback from the broken product on the |> console. | | We usually start Zope with "bin/zopectl start" (because consoles are | not garanteed to remain open). And then you see nothing, when there | are problems during startup.
When debugging a starup problem, I always start the appserver in the foreground, with debug-mode turned on; I then Ctrl-C to kill the foreground process (once it *does* start) and restart it in the background.
The only glitch I see in this approach is that I think starting Zope in the foreground (via 'zopectl fg') should automatically turn on debug-mode; then I wouldn't need to edit zope.conf, and then re-edit it when done.
FWIW, while I don't like the fact that "debug mode" implies a bunch of different things, I do like the "dont start if there's a code error" feature that's implied by the debug-mode behavior. I think the fact that it drives other people nuts is because (unlike me or Tres), when they're developing, they start Zope in a background process. I always start Zope in the foreground when doing development and I don't do any development on production instances so I don't care whether the console goes away or not (I just restart it). I'd prefer not to waste any time clicking around, finding out something doesn't work, then ultimately needing to visit the control panel to look for "broken products". The error log messages that occur after a successful startup that fails to initialize a product (because of, say, a syntax error) are often pretty baroque. - C
On Thu, Mar 10, 2005 at 02:59:42PM -0500, Chris McDonough wrote:
I'd prefer not to waste any time clicking around, finding out something doesn't work, then ultimately needing to visit the control panel to look for "broken products". The error log messages that occur after a successful startup that fails to initialize a product (because of, say, a syntax error) are often pretty baroque.
I'm with Chris on this. I always develop in debug mode and i find the bail-out-on-product-errors behavior useful. -- Paul Winkler http://www.slinkp.com
On Mar 10, 2005, at 20:59, Chris McDonough wrote:
I'd prefer not to waste any time clicking around, finding out something doesn't work, then ultimately needing to visit the control panel to look for "broken products". The error log messages that occur after a successful startup that fails to initialize a product (because of, say, a syntax error) are often pretty baroque.
+10 I develop the exact same way and if there's something stupid like a syntax error on my code I will know *right away*. The "startup death on product load error" is a big time saver for me during development. jens
On 11/03/2005, at 8:35, Tres Seaver wrote:
When debugging a starup problem, I always start the appserver in the foreground, with debug-mode turned on; I then Ctrl-C to kill the foreground process (once it *does* start) and restart it in the background.
The only glitch I see in this approach is that I think starting Zope in the foreground (via 'zopectl fg') should automatically turn on debug-mode; then I wouldn't need to edit zope.conf, and then re-edit it when done.
You can override zope.conf values when using runzope. For example:: runzope -X "debug-mode=on" Would be useful to be able to do the same with zopectl.
participants (8)
-
Bert Vanderbauwhede -
Chris McDonough -
Dieter Maurer -
Jens Vagelpohl -
Josef Meile -
Michael Dunstan -
Paul Winkler -
Tres Seaver