zope.conf: effective-user breaks clean segfault handling

Bug #143623 reported by Christian Theune
2
Affects Status Importance Assigned to Milestone
Zope 2
Invalid
Medium
Unassigned

Bug Description

I have been hunting a segfault problem for about 6 month now and finally found a way to get deeper into it.

Situation:

A Zope server using ZMySQLDA segfaults every now and then. The mysql C-module is likely to be the hotspot. However, no core dump is every issued, and the threads that did not segfault are hanging around.

Software: Python 2.3.5, Zope 2.7.7, and some other stuff that doesn't look too suspicious.

It happens that additionally to the hanging threads, (which are described as a Python bug for a while ago) no core dump is beeing written.

I finally found that the "effective-user" switch somehow influences this.

When making the server run as the effective user immediately and not using a low port, both things work as expected: all threads are killed (and zdaemon cleanly restarts the server) and a core dump is written.

Tags: bug zope
Revision history for this message
Andreas Jung (ajung) wrote :

Is this still an issue? I haven't seen any segfaults with the latest Zope versions since about one yr. Maybe change the importance to medium.

Revision history for this message
Christian Theune (ctheune) wrote :

I think it still happens. We are still experiencing the segfaults (this is still on Zope 2.7 thought and we can't switch.) and are working around the unclean handling when the user was switched.

This is easily provokable by writing a small c-module that segfaults and test if a Zope server that runs as root with a different effective user still hangs.

Revision history for this message
Lennart Regebro (regebro-gmail) wrote :

Such a c-module would be welcome to test if this is an issue on newer Zopes as well.

Andreas Jung (ajung)
Changed in zope2:
importance: Critical → High
Revision history for this message
stephan_hofmockel (dreagonfly) wrote :

I struggled also with (own) c-modules and 'effective-user', so I would like to share my experiences.
First of all, I did my tests with svn://svn.zope.org/repos/main/Zope/tags/2.12.3 Revision: 110486 python2.6 under Linux with Kernel Version 2.6.31

I created a little c-module to simplify work (see attachment). I hooked this module into the Zope via a external method and checked first if zdaemon restarts the server after executing the method.

From my point of view this works fine. The server process is killed completely and a new one is started by zdaemon.

Unfortunately no core-dump was written and I did these three points to get it

 1) 'ulimit -c unlimited' If this value is smaller then the core-file to be written, then no core-file is written.

 2) echo '/tmp/core' > /proc/sys/kernel/core_pattern In default mode the core file is written to the current working directory. For a reason I currently cannot explain, the default doesn't work and only after setting it to a hardcoded path the file appears.

 3) echo -n 2 > /proc/sys/fs/suid_dumpable According to http://www.kernel.org/doc/man-pages/online/pages/man5/proc.5.html for programs executing the seteuid call (which is done by 'dropPrivileges' in Zope2/Startup/__init__.py) no core-file is written by default. Switching this value to 2 changes this behavior.

After applying all these 3 configurations a core-file was created.

Revision history for this message
Tres Seaver (tseaver) wrote :

Thanks very much for providing the C module and describing how to reproduce the segfault, as well as the issues which prevent the generation of a core file (starting Zope as root and dropping privileges, along with the various tweaks required by your OS).

I'm not sure what the proper resolution of the report should be: it doesn't appear to be a bug in Zope which causes either behavior, and running Zope bound to low ports is pretty much an unsupported mode of operation these days. OTOH, we do have a need to have Zope be started by root (e.g., from /etc/init.d), and would prefer to have it be well behaved in such cases.

BTW, the Python bug for "hanging threads after segfault" seems to have been fixed for Python 2.4:

  http://bugs.python.org/issue756924

Revision history for this message
Tres Seaver (tseaver) wrote :

This bug occurs only when running Zope as root, and has a workaround (for Linux at least).

Changed in zope2:
importance: High → Medium
status: New → Triaged
Revision history for this message
Colin Watson (cjwatson) wrote :

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.

Changed in zope2:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.