hi I'm looking for a fairly uncomplicated way to run zope 2.7 without the daemon manager process (as i want to run it under daemontools). This was simple with zope 2.6 but it seems i might need to chuck zope.conf and get my hands dirty to do the same with 2.7. any suggestions? thanks <--> george donnelly ~ http://www.zettai.net/ ~ "Quality Zope Hosting" Shared and Dedicated Zope Hosting ~ Zope Servers ~ Zope Websites Yahoo, AIM: zettainet ~ ICQ: 51907738 ~ Sales (USA): 1-866-967-3669
I'm looking for a fairly uncomplicated way to run zope 2.7 without the daemon manager process (as i want to run it under daemontools). This was simple with zope 2.6 but it seems i might need to chuck zope.conf and get my hands dirty to do the same with 2.7.
any suggestions?
I haven't tried it out yet myself, but you can call runzope directly, which might be enough to make supervise happy. You shouldn't have to throw out zope.conf to make it work, though it won't be clean like a typical djb program. There's still the issue of zope's horrendously overcomplicated logging stuff, but if you just want to get zope supervised I think runzope is what you want to call. -- 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
Yes, use runzope. That's the recommended way to run Zope without a daemon manager. But Jamie what would you have done wrt to logging to make it not so "horrendously overcomplicated"? And what does this have to do with runzope? On Thu, 2004-02-12 at 17:06, Jamie Heilman wrote:
I'm looking for a fairly uncomplicated way to run zope 2.7 without the daemon manager process (as i want to run it under daemontools). This was simple with zope 2.6 but it seems i might need to chuck zope.conf and get my hands dirty to do the same with 2.7.
any suggestions?
I haven't tried it out yet myself, but you can call runzope directly, which might be enough to make supervise happy. You shouldn't have to throw out zope.conf to make it work, though it won't be clean like a typical djb program. There's still the issue of zope's horrendously overcomplicated logging stuff, but if you just want to get zope supervised I think runzope is what you want to call.
Chris McDonough wrote:
But Jamie what would you have done wrt to logging to make it not so "horrendously overcomplicated"? And what does this have to do with runzope?
It doesn't have anything to do with runzope, it has to do with the daemontools service model, whereby you have a program of some type which is "daemonized" and taken care of by supervise and it simply writes its logs to stdout which is connected to a supervised multilog process that handles all the rotation, post-processing, and other mumbo-jumbo you might want to do, as a seperate user, in a seperate process, with seperate resource limits. Hurray for security. Zope doesn't fit particularly well into that model because it wants to handle all the log rotation and all that junk itself. Which, IMHO, is a design flaw, but not a particularly big deal as its easy enough to work around if you really want to. Zope's logging, and indeed the entire python logging module, is really just far too much indirection for me to stomach. I understand why people wanted it, I understand why programmers like it, but it doesn't really excite me in the context of this particular application. -- 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
Well, FWIW, if you want to do this, here's a zope.conf incantation that sends all event and access log output to stdout: <eventlog> level all <logfile> path STDOUT level info </logfile> </eventlog> <logger access> level WARN <logfile> path STDOUT format %(message)s </logfile> </logger> Then you could use multilog to figure out which is which (somehow), and I think all is well. On Thu, 2004-02-12 at 17:42, Jamie Heilman wrote:
Chris McDonough wrote:
But Jamie what would you have done wrt to logging to make it not so "horrendously overcomplicated"? And what does this have to do with runzope?
It doesn't have anything to do with runzope, it has to do with the daemontools service model, whereby you have a program of some type which is "daemonized" and taken care of by supervise and it simply writes its logs to stdout which is connected to a supervised multilog process that handles all the rotation, post-processing, and other mumbo-jumbo you might want to do, as a seperate user, in a seperate process, with seperate resource limits. Hurray for security. Zope doesn't fit particularly well into that model because it wants to handle all the log rotation and all that junk itself. Which, IMHO, is a design flaw, but not a particularly big deal as its easy enough to work around if you really want to. Zope's logging, and indeed the entire python logging module, is really just far too much indirection for me to stomach. I understand why people wanted it, I understand why programmers like it, but it doesn't really excite me in the context of this particular application.
Chris McDonough wrote:
<logger access> level WARN <logfile> path STDOUT format %(message)s </logfile> </logger>
Then you could use multilog to figure out which is which (somehow), and I think all is well.
What is the format directive all about? Can you affect the line as its written to STDOUT with that? If so you could potentialy tag all access logs with some prefix which would make it trivial to seperate them again in multilog using its pattern matching stuff. -- 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
Yes, you can disambiguate the log entries as necessary by prepending some literal string to the message or whatever. The default event log handler format string is "------\n%(asctime)s %(message)s"; the default access log format string is "%(message)s" (the message includes the time). FWIW, the allowable interpolation values are: %(name)s Name of the logger (logging channel) %(levelno)s Numeric logging level for the message (DEBUG, INFO, WARNING, ERROR, CRITICAL) %(levelname)s Text logging level for the message ("DEBUG", "INFO", "WARNING", "ERROR", "CRITICAL") %(pathname)s Full pathname of the source file where the logging call was issued (if available) %(filename)s Filename portion of pathname %(module)s Module (name portion of filename) %(lineno)d Source line number where the logging call was issued (if available) %(created)f Time when the LogRecord was created (time.time() return value) %(asctime)s Textual time when the LogRecord was created %(msecs)d Millisecond portion of the creation time %(relativeCreated)d Time in milliseconds when the LogRecord was created, relative to the time the logging module was loaded (typically at application startup time) %(thread)d Thread ID (if available) %(message)s The result of record.getMessage(), computed just as the record is emitted - C On Thu, 2004-02-12 at 18:04, Jamie Heilman wrote:
Chris McDonough wrote:
<logger access> level WARN <logfile> path STDOUT format %(message)s </logfile> </logger>
Then you could use multilog to figure out which is which (somehow), and I think all is well.
What is the format directive all about? Can you affect the line as its written to STDOUT with that? If so you could potentialy tag all access logs with some prefix which would make it trivial to seperate them again in multilog using its pattern matching stuff.
Jamie Heilman <jamie@audible.transient.net> on 2/12/04 wrote:
I haven't tried it out yet myself, but you can call runzope directly, which might be enough to make supervise happy. You shouldn't have to throw out zope.conf to make it work, though it won't be clean like a typical djb program. There's still the issue of zope's horrendously overcomplicated logging stuff, but if you just want to get zope supervised I think runzope is what you want to call.
ah - good idea. yes seems to work fine so far. I got error/event logging to work with multilog in zope 2.6 by adding this to the start script: STUPID_LOG_FILE= "$@" export STUPID_LOG_FILE EVENT_LOG_FILE= "$@" export EVENT_LOG_FILE not sure how best to do it with zope 2.7 but will be working on it. <--> george donnelly ~ http://www.zettai.net/ ~ "Quality Zope Hosting" Shared and Dedicated Zope Hosting ~ Zope Servers ~ Zope Websites Yahoo, AIM: zettainet ~ ICQ: 51907738 ~ Sales (USA): 1-866-967-3669
george donnelly wrote:
not sure how best to do it with zope 2.7 but will be working on it.
I used to register a simple logger with zLOG that just wrote things to stdout. If you aren't too picky about events actually getting logged in the [correct] order that they really happened, its enough. A more reliable logger requires some serious hacking. -- 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
This is already built-in to 2.7. No hacking required. On Thu, 2004-02-12 at 17:46, Jamie Heilman wrote:
george donnelly wrote:
not sure how best to do it with zope 2.7 but will be working on it.
I used to register a simple logger with zLOG that just wrote things to stdout. If you aren't too picky about events actually getting logged in the [correct] order that they really happened, its enough. A more reliable logger requires some serious hacking.
On Thu, 2004-02-12 at 17:46, Jamie Heilman wrote:
george donnelly wrote:
not sure how best to do it with zope 2.7 but will be working on it.
I used to register a simple logger with zLOG that just wrote things to stdout. If you aren't too picky about events actually getting logged in the [correct] order that they really happened, its enough. A more reliable logger requires some serious hacking.
Chris McDonough wrote:
This is already built-in to 2.7. No hacking required.
Well.. keywords being: simple, reliable (wrt to log order) The built-in logger is neither. Is that a particularly big deal for 99% of the use cases out there? No. -- Jamie Heilman http://audible.transient.net/~jamie/
On Thu, 2004-02-12 at 18:16, Jamie Heilman wrote:
This is already built-in to 2.7. No hacking required.
Well.. keywords being: simple, reliable (wrt to log order) The built-in logger is neither.
I don't know what the Python logger module promises about log order, but it does use thread locks to serialize record emits, so I'm not sure how wrong it could actually get. As far as simplicitly... errr.. it's not currently exactly rocket science. :-) - C
Chris McDonough wrote:
On Thu, 2004-02-12 at 18:16, Jamie Heilman wrote:
This is already built-in to 2.7. No hacking required.
Well.. keywords being: simple, reliable (wrt to log order) The built-in logger is neither.
I don't know what the Python logger module promises about log order, but it does use thread locks to serialize record emits, so I'm not sure how wrong it could actually get.
I observed out of order logs in 2.6.2 ... so it could be the python logging stuff actually fixed this, I haven't done extensive testing. So I shouldn't have said the built-in logger is neither, I should have said it *was* neither, mea culpa. From what I remember the one place in Zope I could get it to happen fairly reliably was the shutdown function in the control panel, though I don't remember the details anymore of how it actually all worked, I figured it out once just out of curriosity. -- 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
participants (3)
-
Chris McDonough -
george donnelly -
Jamie Heilman