[Zope-dev] zope (with cmf) instance being frequently restarted by signal SIGSEGV(11)
Hi, I have a cmf site that has begun restarting frequently and at random intervals for no apparent reason. This first occurred about 2 weeks ago for about 2-3 days with the instance being restarted every 15 mins at worst. This problem disappeared as quickly as it had appeared. 2-3 days ago this same problem reappeared but with the site sometimes being restarted 10 times in a 15 minute period. I can find no sequence of url calls or any common reason for this to be occurring. The only thing I could find was the following entry appearing in the event log matching the times I have witnessed the instance restarting via top. ERROR(200) zdaemon Process 25606 terminated by signal SIGSEGV(11) The only changes that have occurred around the time of this first problem turning up was (other than normal site operation with members/items being add/deleted): -the cpu and memory being upgraded. This was returned to the original memory and cpu state to make sure this wasn't the cause. These have been swapped in/out with no change so it looks like it is just coincidence. There is no obvious signs of anything malicious going on, but this is always a possibility I guess? What to check for? As this has basically brought the site to its knees with proxy errors displayed more often than not, has anyone got suggestions on what to look for. possibilities (however remote) as I am pretty desperate to get this fixed. If there is a simple explanation, what could cause it to start out of the blue? The only possible answer I have come up with while searching is about the thread stack size being to small. And having to recompile python with this set to a larger figure. Is this related to the problem I am having, and is there an easy way to check if this is the case for the version I have running? If this is what I need to do, is there a good link for details on what needs to be done and how to do it? CMF: 1.4.2 Zope: (unreleased version, python 2.1.3, linux2) Python: 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] Thank you for all your help on this as I am lost at what steps to take next. Thanks, Richard. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Help: __getstate__ overriding
I have a Persistent derived class where I want to upgrade from using a
PersistentList to a BTrees.IOBTree.IOBTree.
_articleList is the old Persistent list
_oidsToArticles is the new IOBTree.
def __setstate__(self, state):
articleList = state.get('_articleList')
if articleList:
oidsToArticles = self.makeBTree()
for each in articleList:
oidsToArticles[each.oid()] = each
del state['_articleList']
state['_oidsToArticles'] = oidsToArticles
Persistent.__setstate__(self, state)
This seems to work fine, and I am adding more objects to
_oidsToArticles. The problem is that when I commit the transaction,
nothing is saved. I have tested the same code without __setstate__ and
then it saves just fine. What hoops does one have to jump through to
upgrade the state of a ZODB object?
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
On Friday 28 May 2004 02:48, Philipp von Weitershausen wrote: Garrett Smith wrote: This problem seems analogous to view lookup -- content/++view++index.html and content/@@index.html are equivalent. So, applied to adapters, we could use: content/++adapter++dc/title (or '++adapt++') +1 on ++adapt++. I think using the the traversal machinery and its syntax would be a very elegant solution. Then using either ##, ** or :: as a shortcut (in analogy to @@) would be even more consistent, since in current component-architecture-speak, views are multi-adapters. Just compare them visually: - context/@@absolute_url +1 -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
On Friday 28 May 2004 11:21, Garrett Smith wrote: context/##dc/title Not so good; looks convoluted. context/**dc/title This one looks good. Remind me of the power of a number, like dc takes over context. :-) context/::dc/title I am fine with this one as well. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
On Friday 28 May 2004 11:21, Garrett Smith wrote: What was the reasoning behind selecting @@ for the view namespace shortcut? Because it looks like two eyes. (IIRC, the motivation was to use characters that could be used in URLs, but I'm not sure that's an issue for adapters...or is it?) That was one consideration; there was extensive research done on which characters would be permissible. I do not think we have the same issue with the adapters though. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
Garrett Smith wrote: What was the reasoning behind selecting @@ for the view namespace shortcut? (IIRC, the motivation was to use characters that could be used in URLs, but I'm not sure that's an issue for adapters...or is it?) Legal in urls, no English. @@ looks like two eyes viwing something. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales variable namespaces
I want to thank everyone who's participating in this thread. The input is extremely valuable. Garrett Smith wrote: Jim Fulton wrote: We don't. In fact, one could argue that adaptation is a bit like a different kind of traversal. In fact, in Zope 3, we already have a notion of this. In general, in Zope 3 paths, we can say: foo/++namespace++name where /++namespace++ can be thought of as a special form of namespace operator (similar and partly inspired by xpaths /:namespace:). So, we could also use something like: content/++adapter++dc/title but I think people want something more concide for ZPT. I prefer this notation, even though it's more verbose. I think it should be supported along with a short cut syntax. This problem seems analogous to view lookup -- content/++view++index.html and content/@@index.html are equivalent. So, applied to adapters, we could use: content/++adapter++dc/title (or '++adapt++') one could use: content/##dc/title or perhaps (yuckier): content/**dc/title I'd hate to see Yet Another Traversal Syntax introduced Too late. :) Path expressions already introduce separate syntax. This is, in part, to take advantage of the TALES variable namespaces, which aren't relevent to generic path traversal. when we already have a decent pattern established. We are talking about two different systems here. The ++namespace++name syntax is part of Zope's generic path execution machinery, which Zope 3 TALES uses. When we use this syntax, or @@name. all of the work is done by the namespace machinery, not by TALES. This means that TALES has no control over it. So, if you rely solely on the standard traversal machinery, you won't be able to define short names within the template. I suggest that whatever short syntax we come up with should be handled by TALES, not the standard path traversal machinery. Given that, I still prefer context#dc to context/##dc. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Help: __getstate__ overriding
[Syver Enstad]
I have a Persistent derived class where I want to upgrade from using a
PersistentList to a BTrees.IOBTree.IOBTree.
_articleList is the old Persistent list
_oidsToArticles is the new IOBTree.
def __setstate__(self, state):
articleList = state.get('_articleList')
if articleList:
oidsToArticles = self.makeBTree()
for each in articleList:
oidsToArticles[each.oid()] = each
del state['_articleList']
state['_oidsToArticles'] = oidsToArticles
Persistent.__setstate__(self, state)
This seems to work fine, and I am adding more objects to
_oidsToArticles. The problem is that when I commit the transaction,
nothing is saved.
Quick guess (untested, untried, just from eyeballing this snippet quickly):
nothing is marking self itself as being changed. The only things getting
changed are the throw-away in-memory 'state' dict, the throw-away in-memory
self.__dict__, and a throw-away in-memory BTree. The primary purpose of
p.__setstate__ is to activate a ghost, after which point p is in the
up-to-date state (i.e., not changed -- calling Persistent.__setstate__(self,
...) isn't going to mark self as changed, and nothing in the code above
modifies self itself). If self doesn't look changed, its state in the DB
won't change during commit(), and the DB will still reference your old
PersistentList.
Perhaps shuffling the code around would work, a la:
Persistent.__setstate__(self, state)
articleList = state.get('_articleList')
if articleList is not None:
# make the BTree in local oidsToArticles as above, then
del self._articlelist
self._oidsToArticles = oidsToArticles
The thinking there is that then you've truly modified self, after self has
been activated.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZPT] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: Given that, I still prefer context#dc to context/##dc. +1 I like the idea that '/' and '#' are both path separators, and that the semantics of each path segment depend on the preceding separator. Cheers, Evan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Help: __getstate__ overriding
[Syver Enstad, wants to switch an attribute of a Persitent subclass
From PersistentList to an IOBTree]
[Tim, guessing]
Quick guess (untested, untried, ...
...
Perhaps shuffling the code around would work, a la:
Persistent.__setstate__(self, state)
articleList = state.get('_articleList')
if articleList is not None:
# make the BTree in local oidsToArticles as above, then
del self._articlelist
self._oidsToArticles = oidsToArticles
The thinking there is that then you've truly modified self, after self has
been activated.
Nope, sorry, not a chance. You have truly modified self then, but
__setstate__ is called by magic as part of activation (unghostifying), and
the activation machinery resets self._p_changed after it calls __setstate__.
So same result as your code: the in-memory version of self has the BTree,
but commit() doesn't change anything about self in the database (again
because self._p_changed is false -- and will be no matter what you try to do
in __setstate__()).
This appears to be one of those severely underdocumented minefields. The
best older thread I found is here:
http://mail.zope.org/pipermail/zodb-dev/2002-March/002442.html
but it doesn't actually spell out something that works in the way you
want.
One possibility is to use any of these __setstate__ implementations
temporarily, in a one-shot database conversion script: load every object of
your subclass's type, and for each one obj, after loading it do
obj._p_changed = True
get_transaction().commit()
Note again that setting _p_changed *inside* __setstate__ won't do any good.
Note too that Jim Fulton has a recent proposal for Zope3 in this area:
http://tinyurl.com/ypkhk
[Zope URLs are generally so long my mailer refuses to keep them on one line]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: Given that, I still prefer context#dc to context/##dc. +1, also in preference to /# and the other options I've seen. Gary ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope (with cmf) instance being frequently restarted by signal SIGSEGV(11)
Richard Ettema wrote at 2004-5-28 11:28 +0100: I have a cmf site that has begun restarting frequently and at random intervals for no apparent reason. This first occurred about 2 weeks ago for about 2-3 days with the instance being restarted every 15 mins at worst. This problem disappeared as quickly as it had appeared. 2-3 days ago this same problem reappeared but with the site sometimes being restarted 10 times in a 15 minute period. I can find no sequence of url calls or any common reason for this to be occurring. The only thing I could find was the following entry appearing in the event log matching the times I have witnessed the instance restarting via top. ERROR(200) zdaemon Process 25606 terminated by signal SIGSEGV(11) Let your operating system write core files (usually disabled, read the manual page for ulimit). Analyse the resulting core file with gdb. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Help: __getstate__ overriding
Syver Enstad wrote at 2004-5-28 12:41 +0200:
I have a Persistent derived class where I want to upgrade from using a
PersistentList to a BTrees.IOBTree.IOBTree.
_articleList is the old Persistent list
_oidsToArticles is the new IOBTree.
def __setstate__(self, state):
articleList = state.get('_articleList')
if articleList:
oidsToArticles = self.makeBTree()
for each in articleList:
oidsToArticles[each.oid()] = each
del state['_articleList']
state['_oidsToArticles'] = oidsToArticles
Persistent.__setstate__(self, state)
This seems to work fine, and I am adding more objects to
_oidsToArticles. The problem is that when I commit the transaction,
nothing is saved. I have tested the same code without __setstate__ and
then it saves just fine. What hoops does one have to jump through to
upgrade the state of a ZODB object?
This does not work as changes made in __setstate__ are not
explicitly persisted. Whether or not they become persistent
depends on whether the object is changed again outside __setstate__.
Use an explicit conversion script instead...
--
Dieter
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Bug Day status report (fwd)
[This was mistaken for spam by our filter, and i was too quick to confirm it as spam...] -- Forwarded message -- Date: Fri, 28 May 2004 18:02:50 -0400 From: Paul Winkler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug Day status report Just a quick status report on today's Bug Day... 10 bugs resolved, 5 set to won't fix, 4 rejected. RESOLVED: #1213, #852, #1293, #1355, #1265, #1352, #1094, #993, #1132, #596 WONTFIXED: #1193, #329, #1098, #1045, #981 REJECTED: #639, #1238, #489, #1297 The #zope-dev channel is quiet now, but feel free to hop in and rev it up again :-) -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
