Zope3 server with SIGSEGV - what to do?
Hi, In my Zope3 (I use Zope 3.4.0) logs I just found some curious entries: ------------------------------ snip ----------------------- 2009-10-23T12:20:41 INFO root pid 21278: terminated by SIGSEGV ------ 2009-10-23T12:20:41 INFO root spawned process pid=1502 ------ 2009-10-23T12:21:12 INFO WSGIHTTPServer zope.server.http (WSGI-HTTP) started. Hostname: zis Port: 8088 ------ 2009-10-23T12:21:12 INFO root Startup time: 24.212 sec real, 16.580 sec CPU ------------------------------ snip ----------------------- This occurs once in a while, so it seems something segfaults and the server seems to notice that and restarts. Any clue what to do about this? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Tue, Nov 24, 2009 at 4:04 PM, Hermann Himmelbauer <dusty@qwer.tk> wrote:
This occurs once in a while, so it seems something segfaults and the server seems to notice that and restarts.
Any clue what to do about this?
If you're using a version of zope.security less than 3.7.1, I would suspect https://bugs.launchpad.net/zope3/+bug/181833. -- Benji York
Am Dienstag 24 November 2009 22:12:00 schrieb Benji York:
On Tue, Nov 24, 2009 at 4:04 PM, Hermann Himmelbauer <dusty@qwer.tk> wrote:
This occurs once in a while, so it seems something segfaults and the server seems to notice that and restarts.
Any clue what to do about this?
If you're using a version of zope.security less than 3.7.1, I would suspect https://bugs.launchpad.net/zope3/+bug/181833.
Ah, thanks that could be. My current version is zope.security-3.4.1 (as from KGS-3.4.0). The real bad thing about this is that it seems I'm stuck with that release as trying to upgrade to zope.security-3.7.1 fails due to dependencies. So I'd have to upgrade all packages (btw., there seems not to be any current KGS?). Unfortunately that seems to be impossible, as I'm stuck to Python 2.4, as my database (SAPDB) has no support for Python > 2.4... Any ideas how to solve this? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Wed, Nov 25, 2009 at 1:42 AM, Hermann Himmelbauer <dusty@qwer.tk> wrote:
Ah, thanks that could be. My current version is zope.security-3.4.1 (as from KGS-3.4.0).
The real bad thing about this is that it seems I'm stuck with that release as trying to upgrade to zope.security-3.7.1 fails due to dependencies. So I'd have to upgrade all packages (btw., there seems not to be any current KGS?).
Yep. The introduction of so many non-backward-compatible changes in the last few years has also caused me great pain.
Any ideas how to solve this?
If this bug did indeed exist in 3.4.1, we can backport the fix and do a 3.4.x bug-fix release. -- Benji York
Am Mittwoch 25 November 2009 13:07:58 schrieb Benji York:
On Wed, Nov 25, 2009 at 1:42 AM, Hermann Himmelbauer <dusty@qwer.tk> wrote:
Ah, thanks that could be. My current version is zope.security-3.4.1 (as from KGS-3.4.0).
The real bad thing about this is that it seems I'm stuck with that release as trying to upgrade to zope.security-3.7.1 fails due to dependencies. So I'd have to upgrade all packages (btw., there seems not to be any current KGS?).
Yep. The introduction of so many non-backward-compatible changes in the last few years has also caused me great pain.
Any ideas how to solve this?
If this bug did indeed exist in 3.4.1, we can backport the fix and do a 3.4.x bug-fix release.
Thanks a lot for help, that would really great. The question is, how do I find out (with my limited knowledge of zope.security) if the bug exists in 3.4.1? I saw in your link you sent me that a core-dump can be made somehow, how can this be done? Because via that core-dump I expect we can pinpoint the reason and confirm the bug for zope.security-3.4.1? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Thu, Nov 26, 2009 at 6:52 AM, Hermann Himmelbauer <dusty@qwer.tk> wrote:
If this bug did indeed exist in 3.4.1, we can backport the fix and do a 3.4.x bug-fix release.
Thanks a lot for help, that would really great. The question is, how do I find out (with my limited knowledge of zope.security) if the bug exists in 3.4.1?
From looking at the code, it seems the bug does exist in 3.4.1 (and 3.4.2). I merged the fix to the 3.4 branch and released 3.4.3.
I saw in your link you sent me that a core-dump can be made somehow, how can this be done? Because via that core-dump I expect we can pinpoint the reason and confirm the bug for zope.security-3.4.1?
As a first step, I suggest putting 3.4.3 in production and seeing if the segfaults stop. -- Benji York
participants (2)
-
Benji York -
Hermann Himmelbauer