Zope May 2015

zope@zope.dev

9 participants
6 discussions

Zope loses data irretrievably upon restart
by Tom Cameron 27 May '15

27 May '15

We’ve been running Zope servers for about 15 years. In the last few years we have had a number of Zope servers instantly lose data upon restart. This has happened to us about 5 times over the past 2 years on 4 different servers. Upon restarting Zope we notice a rollback of data to sometimes months old and a Data.fs with a much older timestamp than expected. At this point the data was irretrievable. We find that it is not in any backups or anywhere on the file system. We have finally worked out what is happening but not exactly why. Below is a detailed explanation of what we are seeing. We are keen to know if anybody else is having similar issues or if perhaps we have setup something incorrectly and need to change how we pack the database. Also this may serve as a warning to others. *Explanation* The issue is that Zope is losing the file descriptor, the Data.fs still remains in the folder but Zope keeps writing to a (deleted) file descriptor which can be seen with lsof. Every server affected by this was running ZEO and had zeopack in the default configuration. We believe for some reason when zeopack tries to pack the ZODB, that when the Data.fs is moved and renamed to Data.fs.old and eventually deleted, Zope doesn’t recognize the new file. This is what we believe happens: 1. Zope is connected to a file Data.fs. 2. zeopack packs this file into a new file Data.fs.tmp 3. zeopack deletes any file named Data.fs.old 4. zeopack then renames Data.fs to Data.fs.old 5. zeopack then renames Data.fs.tmp to Data.fs The problem is that Zope is connected directly to the Data.fs file via its handler and even though it is renamed it continues to write to Data.fs.old. Later on, we do a subsequent zeopack and the Data.fs.old file is deleted in the process, but Zope keeps writing to this deleted file. We now have a situation where Zope is connected to a deleted file and is writing all its data to it. If Zope is ever stopped, the connection is lost and so effectively is the file. It is true that expert forensics could retrieve the file but in the first few instances that this happened we were totally baffled as to where the data had gone. In one case we had not restarted Zope for 4 months and thus we lost 4 months of data. *Environment* We are running standard Plone servers on Debian 5.0.10 in this case, with following: - Plone 4.3.4.1 (4309) - CMF 2.2.8 - Zope 2.13.22 - Python 2.7.8 (default, Jan 27 2015, 14:19:28) [GCC 4.3.2] - PIL 2.3.0 (Pillow) - ZEO: plone.recipe.zeoserver 1.2.6 Effective-user is set correctly for this instance “landcarevic” and properly mounts the Data.fs under normal circumstances. *Detailed Symptoms* This is a real case we discovered and managed to retrieve the lost file. Zope will continue to write to a Data.fs that has been technically deleted. We are able to notice this because the Data.fs.tmp will have a much more recent timestamp than the Data.fs in the var/filestorage directory. -rw-r--r-- 1 landcarevic psacln 6735952811 2015-04-12 00:11 Data.fs -rw-r--r-- 1 landcarevic psacln 18594749 2015-04-12 00:11 Data.fs.index -rw-r--r-- 1 landcarevic psacln 6 2015-03-30 11:20 Data.fs.lock -rw-r--r-- 1 landcarevic psaserv 14600344 2015-05-26 10:27 Data.fs.tmp An “lsof | grep Data.fs” can show if the file descriptor is pointing to a deleted file on the fs: python2.7 9307 landcarevic 7uW REG 0,31 6 4986845 /var/www/vhosts/ landcarevic.net.au/plone43/var/filestorage/Data.fs.lock python2.7 9307 landcarevic 11u REG 0,31 14600344 4986235 /var/www/vhosts/ landcarevic.net.au/plone43/var/filestorage/Data.fs.tmp python2.7 9307 landcarevic 12u REG 0,31 7058741434 4986349 (deleted)/var/www/vhosts/ landcarevic.net.au/plone43/var/filestorage/Data.fs.old The process id for the instance is 9307 and it’s still holding open a Data.fs.old that has been deleted. Most likely due to a ZEO pack before from the cron in this case. Because it packs the Data.fs and then moves the old one to Data.fs.old which eventually gets deleted. But Zope never properly recognises the new Data.fs for some reason. *Recovery* As long as the Zope server doesn’t get shut down or restarted, it will hold this open and continue to write to the disk. It can be recovered by copying from /proc where /proc/{process ID}/fd/{file descriptor ID} can be found from running lsof as previously: # cp /proc/9307/fd/12 /home/alyssa/Data.fs-current # ls -al /home/alyssa/ ... -rw-r--r-- 1 root root 7058741434 2015-05-26 11:11 Data.fs-current Which has the correct timestamp and file size. -- *Tom Cameron*

2 1

Iterating over objects in ZODB
by Rich Harley 21 May '15

21 May '15

When iterating over dtml objects, the contents of those scripts can be returned: e.g. for item in context.objectValues(): if item.meta_type=='DTML Method’: print item But when iterating over Python Scripts, only: <PythonScript at handleday> is returned. How can I access the actual contents of the Python Script? Thanks Rich

4 3

ZCatalog queries performance
by Sebastian Tänzer 19 May '15

19 May '15

Hello, I’m querying a ZCatalog with a lot of indexes and some meta data for event objects to get related events by tags. These need to be displayed with a title image (which itself is a sub object of the event object) and a pre-defined short text. My python query script gets the results, I then loop over them and get the object with unrestrictedTraverse(x.getPath(), None). I understood getObject is not really performant, but getting the objects with unrestrictedTraverse is not a lot faster. What would be the best way to query for these objects and then display the results with the image? Should I add the url of the image as meta data (title_image etc.)? What is the best way to display search results? Is getting the whole object via unrestrictedTraverse() a good idea? What are the alternatives? Best, Sebastian

2 4

Re: [Zope] Zope Digest, Vol 127, Issue 3
by Rich Harley 17 May '15

17 May '15

Thanks both. .body() is the simple answer, .read() also works. Rich ---- > > Message: 1 > Date: Wed, 13 May 2015 11:36:03 +0000 > From: Rich Harley <raharley0(a)gmail.com> > To: zope(a)zope.org > Subject: [Zope] Iterating over objects in ZODB > Message-ID: <86A3FE9B-5060-4D9A-B5BA-7F96AACD7361(a)gmail.com> > Content-Type: text/plain; charset=windows-1252 > > When iterating over dtml objects, the contents of those scripts can be returned: > > e.g. > > for item in context.objectValues(): > if item.meta_type=='DTML Method?: > print item > > > But when iterating over Python Scripts, only: > > <PythonScript at handleday> > > is returned. How can I access the actual contents of the Python Script? > > Thanks > Rich > > ------------------------------ > > Message: 2 > Date: Wed, 13 May 2015 13:57:30 +0200 > From: Niels Dettenbach <nd(a)syndicat.com> > To: zope(a)zope.org > Subject: Re: [Zope] Iterating over objects in ZODB > Message-ID: <2201822.Nhz8cIhMP1@gongo> > Content-Type: text/plain; charset="us-ascii" > > Am Mittwoch, 13. Mai 2015, 11:36:03 schrieb Rich Harley: >> is returned. How can I access the actual contents of the Python Script? > The python script object seems a bit more complex then a DTML-Method object - > means you have to access the script content of the python script object > directly (not shure if it's "params" and "body" - have to look into Zope help > (PythonScript.py) or Zope sources for the exact "field"). > > regarduing the object docs it shoudl work with .read() directly (if it IS a > PythonScript object) or "document_src": > > def read(): > """ > > Return the body of the Python Script, with a special comment > block prepended. This block contains meta-data in the form of > comment lines as expected by the 'write' method. > > """ > def document_src(REQUEST=None, RESPONSE=None): > """ > > Return the text of the 'read' method, with content type > 'text/plain' set on the RESPONSE. > > """ > > > hth a bit and works, > > > Niels. > -- > --- > Niels Dettenbach > Syndicat IT & Internet > http://www.syndicat.com > PGP: https://syndicat.com/pub_key.asc > --- > > > > >

1 0

ZEO manageUndo not working - DisconnectedError
by Sebastian Tänzer 06 May '15

06 May '15

Hello once more, I’m running a fresh Zope2 ZEO setup (pip install --index-url=http://download.zope.org/Zope2/index/2.13.22/ Zope2 and pip install zope.mkzeoinstance) inside a virtualenv setup. As said: No products, fresh setup, happens with any object. Going to any undo tab produces this error: Error Type: DisconnectedError Client log: 2015-05-06 01:16:46 INFO ZEO.ClientStorage zeostorage Disconnected from storage: "('localhost', 9999)" 2015-05-06 01:16:46 ERROR Zope.SiteErrorLog 1430867806.070.275579780745 http://192.168.10.38:8080/temp_folder/manage_UndoForm Traceback (innermost last): Module ZPublisher.Publish, line 138, in publish Module ZPublisher.mapply, line 77, in mapply Module ZPublisher.Publish, line 48, in call_object Module Shared.DC.Scripts.Bindings, line 322, in __call__ Module Shared.DC.Scripts.Bindings, line 359, in _bindAndExec Module App.special_dtml, line 185, in _exec Module App.Undo, line 112, in undoable_transactions Module ZODB.DB, line 901, in undoInfo Module ZEO.ClientStorage, line 1283, in undoInfo Module ZEO.ServerStub, line 285, in undoInfo Module ZEO.zrpc.connection, line 776, in call Module ZEO.zrpc.connection, line 796, in wait DisconnectedError 2015-05-06 01:16:46 WARNING ZEO.zrpc (19205) CW: error connecting to ('::1', 9999): ECONNREFUSED 2015-05-06 01:16:46 INFO ZEO.ClientStorage zeostorage Testing connection <ManagedClientConnection ('127.0.0.1', 9999)> 2015-05-06 01:16:46 INFO ZEO.zrpc.Connection('C') (127.0.0.1:9999) received handshake ‚Z3101' ZEO server log: 2015-05-06T01:15:13 INFO ZEO.zrpc.Connection('S') (127.0.0.1:47063) received handshake 'Z3101' ------ 2015-05-06T01:16:46 ERROR ZEO.zrpc (19082) can't decode message: '(K\x9dI00\nU\x08undoInfo(K\x00K\x14}U\x0bdescriptioncco...' ------ 2015-05-06T01:16:46 ERROR ZEO.zrpc.Connection('S') (127.0.0.1:47063) Error caught in asyncore Traceback (most recent call last): File "/opt/python/2.7.9/lib/python2.7/asyncore.py", line 83, in read obj.handle_read_event() File "/opt/python/2.7.9/lib/python2.7/asyncore.py", line 449, in handle_read_event self.handle_read() File "/opt/python/zope2-latest/lib/python2.7/site-packages/ZEO/zrpc/smac.py", line 240, in handle_read self.message_input(msg) File "/opt/python/zope2-latest/lib/python2.7/site-packages/ZEO/zrpc/connection.py", line 417, in message_input msgid, async, name, args = self.decode(message) File "/opt/python/zope2-latest/lib/python2.7/site-packages/ZEO/zrpc/marshal.py", line 80, in server_decode return unpickler.load() # msgid, flags, name, args File "/opt/python/zope2-latest/lib/python2.7/site-packages/ZEO/zrpc/marshal.py", line 120, in server_find_global raise ZRPCError("import error %s: %s" % (module, msg)) ZRPCError: import error copy_reg: ------ 2015-05-06T01:16:46 INFO ZEO.StorageServer (127.0.0.1:47063) disconnected The path difference in /opt/python/2.7.9/lib/python2.7/asyncore.py vs /opt/python/zope2-latest/lib/python2.7/site-packages make me wonder if this is a bug or a problem with my setup? Client + ZEO server were created from the same virtualenv. Python 2.7.9 build from source. Any ideas? Best, Sebastian

3 6

manage_renameObjects with remote ZEO
by Sebastian Tänzer 05 May '15

05 May '15

Hello Zope community, does anyone know how to rename a OFS.Folder object from a remote python script (i.e. command line)? I’m trying this via ZEO.ClientStorage, but it fails with "The object <em>renametest1</em> does not support this operation.“ ,triggered by OFS/CopySupport.py", line 537, in _verifyObjectPaste. Full test case code is at http://pastebin.com/j9HY3PVJ At first I thought this is because of a missing REQUEST and/or authentication problem, as _verifyObjectPaste does some security checks or else fails with this message. Still, using makerequest and newSecurityManager doesn’t work. Any help would be greatly appreciated :-) Best Sebastian - tänzermedien GmbH - Agentur für Online-Medien Kekuléstr. 39 | 53115 Bonn, Germany E-Mail: st(a)taenzer.me | Web: http://www.taenzer.me Tel.: 0228-304134-0 | Fax.: 0228-304134-99

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Zope May 2015