how do I manage a graceful shutdown?
I want to do a graceful shutdown with a Product I'm writing. That is, I want to guarantee that some log files include a final message, maybe send an email to a site admin ... those sorts of things. Is there a "hook" that I can include in my product to make sure my shutdown stuff is called whenever Zope is shutting down or restarting? thanks! tim lynch tlynch@nal.usda.gov
Magnus Heino wrote:
Is there a "hook" that I can include in my product to make sure my shutdown stuff is called whenever Zope is shutting down or restarting?
Zope/lib/python/Signals/Signals.py
Signal handlers won't be called during a shutdown from the ZMI. There is http://dev.zope.org/Wikis/DevSite/Proposals/CleanShutdown which is supposedly in CVS and has been vetted, but its not in 2.6.1, and I guess, even if it was, it doesn't look like it offers much in the way of hooks for products to play with. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
On Thursday 20 February 2003 7:52 am, Jamie Heilman wrote:
Magnus Heino wrote:
Is there a "hook" that I can include in my product to make sure my shutdown stuff is called whenever Zope is shutting down or restarting?
Zope/lib/python/Signals/Signals.py
Signal handlers won't be called during a shutdown from the ZMI. There is http://dev.zope.org/Wikis/DevSite/Proposals/CleanShutdown which is supposedly in CVS and has been vetted, but its not in 2.6.1,
It is in the trunk for 2.7, and it is in a branch that merges cleanly with 2.6.x. The change is too deep for the maintenance branch.
and I guess, even if it was, it doesn't look like it offers much in the way of hooks for products to play with.
Read the code. It allows medusa-registered sockets to manage the shutdown process. http://cvs.zope.org/Zope/lib/python/Lifetime.py?only_with_tag=toby-clean-shu... -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Toby Dickenson wrote:
Read the code. It allows medusa-registered sockets to manage the shutdown process.
OK, so if one had a Product that they wanted to be lifetime aware, do you have an example of how one could one use this API? -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
On Thursday 20 February 2003 9:48 pm, Jamie Heilman wrote:
Toby Dickenson wrote:
Read the code. It allows medusa-registered sockets to manage the shutdown process.
OK, so if one had a Product that they wanted to be lifetime aware, do you have an example of how one could one use this API?
I hope youve read the documentation in Lifetime.py. I include it below. First you need to work out what phase of the shutdown process you need to take action in, or delay. The easiest example is from the HTTP Server. It includes this code to close the listening socket (the socket that receives new connections) in phase 2 def clean_shutdown_control(self,phase,time_in_this_phase): if phase==2: self.log_info('closing HTTP to new connections') self.close() Sockets for http clients have this code that keeps zope in shutdown phase 3 for as long as there is still a request in progress. def clean_shutdown_control(self,phase,time_in_this_phase): if phase==3: # This is the shutdown phase where we are trying to finish processing # outstanding requests, and not accept any more self.no_more_requests = 1 if self.working or self.writable(): # We are busy working on an old request. Try to stall shutdown return 1 else: # We are no longer busy. Close ourself and allow shutdown to proceed self.close() return 0 # The shutdown phase counts up from 0 to 4. # # 0 Not yet terminating. running in main loop # # 1 Loss of service is imminent. Prepare any front-end proxies for this happening # by stopping any ICP servers, so that they can choose to send requests to other # Zope servers in the cluster. # # 2 Stop accepting any new requests. # # 3 Wait for all old requests to have been processed # # 4 Already terminated # # It is up to individual socket handlers to implement these actions, by providing the # 'clean_shutdown_control' method. This is called intermittantly during shutdown with # two parameters; the current phase number, and the amount of time that it has currently # been in that phase. This method should return true if it does not yet want shutdown to # proceed to the next phase. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Toby Dickenson wrote:
On Thursday 20 February 2003 9:48 pm, Jamie Heilman wrote:
OK, so if one had a Product that they wanted to be lifetime aware, do you have an example of how one could one use this API?
I hope youve read the documentation in Lifetime.py.
I had, and thats why I asked, because I didn't understand how a product, that has nothing to do with socket handling, was supposed to gain awareness from this API. When I said:
and I guess, even if it was, it doesn't look like it offers much in the way of hooks for products to play with.
And you replied with:
Read the code. It allows medusa-registered sockets to manage the shutdown process.
I interpretted this to imply that I was wrong, that the CleanShutdown code did provide a generic product hook. I mentioned CleanShutdown because Lifetime.py struck me as a logical place to provide something like Tim is looking for. Its been my opinion for some time that Zope could benefit from an internal "init(8)-style" API that products could hook into. With the introduction of Lifetime.py and the CleanShutdown proposal it looked like perhaps such a framework could have a home, though upon futher inspection it looks like Lifetime.py is designed to only be concerned with the lifetime of asyncore, and not of Zope & the ZODB in general. Thus, in short Tim, no, there doesn't appear to be a simple solution to your problem, unless your "products" happen to be socket handlers or the atexit module's semantics don't bother you. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
On Friday 21 February 2003 9:31 am, Jamie Heilman wrote:
Its been my opinion for some time that Zope could benefit from an internal "init(8)-style" API that products could hook into.
Aha! you want to be *notified* of shutdown, rather than participate in a gradual, *staged* shutdown. Yes, Lifetime.py is the wrong area.
inspection it looks like Lifetime.py is designed to only be concerned with the lifetime of asyncore, and not of Zope & the ZODB in general.
Thus, in short Tim, no, there doesn't appear to be a simple solution to your problem, unless your "products" happen to be socket handlers
Yes
or the atexit module's semantics don't bother you.
What problems could there be in atexit semantics? The atexit documentation does say: | the functions registered via this module are not called when the | program is killed by a signal Note that this does not apply if Zope is closed using a SIGTERM or SIGINT. Zope will catch those signals, close gracefully, and call atexit-registered functions. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Toby Dickenson wrote:
Aha! you want to be *notified* of shutdown, rather than participate in a gradual, *staged* shutdown.
yep
What problems could there be in atexit semantics?
Just the stuff Dieter mentioned about the ZODB being closed by that time, afaik--could be something of an inconvenience. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
I wrote my original question a week or so ago then promptly disappeared to take care of some family business. So, thanks to all of you for carrying on this discussion which I'm just now catching up on. yes, what I want is for my product to be notified of an impending shutdown so it can do whatever it needs to "close up shop" so to speak. Given the problems with each approach that's been suggested, I'll probably skip this idea for now, though it seems to me that it'd be a good thing to have a standard way for a product to register a request for notification of shutdown. This might result in product authors having to be extra careful in how they _write_ their products ... but still, I think it'd be useful. anyway, thanks guys for suggestions. --- Tim Lynch tlynch@nal.usda.gov
Toby Dickenson wrote:
Aha! you want to be *notified* of shutdown, rather than participate in a gradual, *staged* shutdown.
yep
What problems could there be in atexit semantics?
Just the stuff Dieter mentioned about the ZODB being closed by that time, afaik--could be something of an inconvenience.
-- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Tim Lynch wrote at 2003-2-18 14:35 EST:
I want to do a graceful shutdown with a Product I'm writing. That is, I want to guarantee that some log files include a final message, maybe send an email to a site admin ... those sorts of things.
Is there a "hook" that I can include in my product to make sure my shutdown stuff is called whenever Zope is shutting down or restarting?
The Python module "atexit" might help you... It might be a bit late when the exit handler is called. You will need to reopen a ZODB connection when you need to access Zope objects. Dieter
participants (5)
-
Dieter Maurer -
Jamie Heilman -
Magnus Heino -
Tim Lynch -
Toby Dickenson