Chris Withers wrote:
Gitte Wange wrote:
Diskspace is 3.3GB left - should be plenty for now ;) ulimit? I have never used it.
Then find out more about it and check if it's resulting in your Zope dying ;-)
You're right - it could have been an issue (or it can be in the future) - it's not the case this time (I'm almost sure of now I come to think of it)
Checking logs etc doens't give me a clue that anyting could be wrong. It's very weird since I have a lot of similar instances running on the same machine that runs perfectly.
Check the size of your Data.fs file, if it's close to 2GB, then you need to make sure you filesystem and python support large files. Also check the amount of space free on wherever temporary files are stored on that server...
And now I think we are getting close to the problem. Data.fs IS around 2GB (2147483592 bytes to be exact). I will try to find out how FreeBSD likes that big files.
I have moved the recovered Data.fs to another machine (and another Zope) trying to start the bastard under Zope-2.7 leaving me with this error when I start Zope:
ZODB.POSException.ConflictError: database conflict error (oid 0000000000000013, serial was 034acb34875e1bcc, now 0000000000000000)
I'm not sure if it's a result of the recovery or if the Data.fs is just broken.
What products do you have installed? This means a product is trying to modify something that another product is also trying to modify on startup. It shouldn't really be possible to happen, but I have seen it when using PTS and multiple ZEO clients, but I don't think that's what you're doing here ;-)
Well the product it fails with is CMFArticle. It shouldn't do anything at startup but if the Data.fs is hitting a filesize limit that would make the instance crash. Thanks for booting my brain Chris :) I hope the problem is "just" that the Data.fs is too big. Greetings, Gitte Wange