[Zope-dev] Re: Log rotation on Windows

Mark Hammond mhammond at skippinet.com.au
Tue Jan 25 16:50:32 EST 2005


[Duncan]

> +1 on fixing the problem of log rotation on windows.
>
> I don't like a solution that requires you to wait an
> arbitrary period for
> the snapshot to appear.

Yes, I see your concern.  Assuming we stick to a rename operation, the
external process could simply wait for the expected file to appear (using,
say, FindFirstChangeNotification or ReadDirectoryChanges).  Even a loop with
1 second sleeps before checking the file should work.

> Especially given that windows has a
> tendency to
> swap processes out to disc just because they haven't done anything
> recently. This means that if you run the logrotate at
> midnight you might
> easily spend the 5 seconds just swapping Zope back into
> memory. Given that
> you don't have a system 'kill' command so you'll need to run
> something zope
> specific to generate the equivalent, you might as well make
> it two-way to
> begin with and signal when the snapshot has been created.

Certainly that is doable, and it touches on a subject I (indirectly) brought
up here quite some time ago - a general notification mechanism so Zope can
let its "parent" know its status (eg, "starting", "running", etc).  If we
can get a more generic notification scheme off the ground, it may make sense
to reuse that.

OTOH, it adds a level complexity where a slightly smarter "wait for file to
appear" loop in the external process may be all that is needed.

> I guess that the most obvious Windows equivalent of the kill
> command would > be to use win32event.CreateEvent() to create
> a named event. That can then be easily signalled from outside
> zope, but a thread inside zope would have
> to explicitly wait on the event (unless
> RegisterWaitForSingleObject could
> be used, but it isn't currently exposed in win32event).

Yep - that is exactly what I was thinking.

> Adding a thread to handle windows events to Zope could also
> be used to improve the communication when run as a service.
> Currently the zope process is terminated using
> TerminateProcess and it would be nicer if the service
> could generate a termination signal to give Zope a chance to shutdown
> cleanly and only resort to TerminateProcess if the clean shutdown was
> ignored.

Collector issues 1527 and 1533 provide startup/shutdown for Windows as it
exists on Linux, hopefully making that moot.  As mentioned above, it has
been identified that Zope really could do with a generic notification
mechanism to improve the situation on all platforms.

I believe that if we keep the task small (ie, just log rotation), we can
come up with a fairly minimal patch which does the job perfectly.  I'm
concerned that if we try and expand it into any kind of generic mechanism,
it simply will not happen.

I note that the only comments you made were on the mechanics of the
operation - which is good!  I expected the scheme itself (ie, "rename to
.snapshot if possible") to be contentious.

Assuming no other serious objections come up, we will steam ahead!

Thanks,

Mark.



More information about the Zope-Dev mailing list