[Zope] Can't stop Zope, machine hanging
Chris McDonough
chrism at plope.com
Wed Sep 13 14:40:32 EDT 2006
On Sep 13, 2006, at 1:57 PM, Ken Ara wrote:
> I have a new problem but it's related, so I'll keep
> this thread alive.
>
> To recap: possibly due to some network problems at my
> hosting provider, my Zope would periodically stop
> responding and I was unable to stop, restart or kill
> it, or even restart the machine remotely. I am
> operating within a FreeBSD jail. Finally, I was given
> a password to the main os environment, allowing me to
> restart, which I have needed to do once.
>
> While waiting for my ISP to resolve his problems, I
> thought it would be a good idea to relieve any excess
> strain on Zope. Part of the strategy involved setting
> Squid to ignore no-cache headers. Call me an
> anti-social protocol violator, but it's still my
> website and I set the caching headers according to the
> page update schedule. But I digress.
>
> Anyway, with response times improved, friendly search
> engines went into a feeding frenzy and within 48 hours
> my ZODB had reached 9GB. Packing time...
Ouch. What on your site generates these writes?
>
> Now, perhaps due to the machine restart I get the
> following error when attempting to pack:
>
> Traceback (innermost last):
> Module ZPublisher.Publish, line 101, in publish
> Module ZPublisher.mapply, line 88, in mapply
> Module ZPublisher.Publish, line 39, in call_object
> Module App.ApplicationManager, line 428, in
> manage_pack
> Module ZODB.DB, line 555, in pack
> Module ZODB.FileStorage, line 1570, in pack
> Module ZODB.fspack, line 700, in pack
> Module ZODB.fspack, line 455, in findReachable
> Module ZODB.fspack, line 475, in buildPackIndex
> Module ZODB.fspack, line 166, in checkTxn
> Module ZODB.fspack, line 161, in fail
> CorruptedError:
> /usr/local/www/Zope/zope01/var/Data.fs:3116771801:time-stamp
> reduction: 0x03681c50ebb292dd <= 0x03681c530eb31b99
>
> The bulk of the database was added following the
> restart so truncating may not be realistic. I haven't
> tried - was it fsrecover? - what is the current best
> tool or strategy?
Fsrecover is a good thing to try. Note that I believe this error
indicates that your system's clock "went back in time" significantly
between two transactions. You're using a fairly old version of Zope,
so I don't know what provisions its ZODB has to protect you against
this sort of thing; I do know that some work was put into dealing
with this sort of case at some point.
- C
More information about the Zope
mailing list