Untrusted developers
Howdy, I work with a Zope deployment at a University. Each school has a folder within the Zope deploy where they have complete control. We allow each student, staff, and faculty member to have their own personal folder. One of the problems with this is that users can write a script which loops indefinitely. When a script gets stuck in a loop it bogs down the ZEO client running it until the system kills that python process. Usually this is because someone is developing something new, when it doesn't work they make a change and try it again. Eventually all of the ZEO Clients are hung and everything is slow (and Zope looks bad to the bosses because this didn't happen with apache.) What I would like to see is a timeout associated with code objects (Python Scripts, Page Templates) that is set to some small value like 10 seconds by default. If the script does not complete within the timeout Zope would raise an exception. The user could bump up the timeout if they are writing something time intensive on purpose, but they wouldn't kill the whole web server (and important web pages) during development. Has anything like this been considered previously? Is it something that would ever make it into a zope release if I was to work on a patch? Thank you, Brian Brinegar Engineering Computer Network Purdue University
This would be a fairly difficult thing to do internal to Zope given the numerous ways people can write infinite loops. You might want to take a look at the Autolance product at http://www.zope.org/Members/mcdonc/Products/AutoLance. It wasn't written for this scenario but might work anyway. On Thu, 2003-07-17 at 12:10, Brian Brinegar wrote:
Howdy,
I work with a Zope deployment at a University. Each school has a folder within the Zope deploy where they have complete control. We allow each student, staff, and faculty member to have their own personal folder.
One of the problems with this is that users can write a script which loops indefinitely. When a script gets stuck in a loop it bogs down the ZEO client running it until the system kills that python process. Usually this is because someone is developing something new, when it doesn't work they make a change and try it again. Eventually all of the ZEO Clients are hung and everything is slow (and Zope looks bad to the bosses because this didn't happen with apache.)
What I would like to see is a timeout associated with code objects (Python Scripts, Page Templates) that is set to some small value like 10 seconds by default. If the script does not complete within the timeout Zope would raise an exception. The user could bump up the timeout if they are writing something time intensive on purpose, but they wouldn't kill the whole web server (and important web pages) during development.
Has anything like this been considered previously? Is it something that would ever make it into a zope release if I was to work on a patch?
Thank you, Brian Brinegar Engineering Computer Network Purdue University
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
On Thu, Jul 17, 2003 at 11:10:45AM -0500, Brian Brinegar wrote:
One of the problems with this is that users can write a script which loops indefinitely. When a script gets stuck in a loop it bogs down the ZEO client running it until the system kills that python process.
We're talking about the process on the Zope, not ZEO server, right? Does the process continue even though the request for it has terminated? I think that I recall that it does. (I don't understand why it works that way.) Is this true for both FastCGI and regular (proxied) HTTP requests? Just being able to kill processes when their requests have been terminated would improve the situation dramatically. It would also allow termination policies to be implemented in the front-end server (Apache). This would not be as nice as the suggestion you made, but we could whip up a simple solution quickly. Can you programmatically determine when a process is associated with a terminated request or is it a fuzzy exercise (like watching "top" for awhile)? Do you use /Control_Panel/DebugInfo? When you find it, is it sufficient and safe to just kill it? --kyler
Just being able to kill processes when their requests have been terminated would improve the situation dramatically. It would also allow termination policies to be implemented in the front-end server (Apache). This would not be as nice as the suggestion you made, but we could whip up a simple solution quickly.
Can you programmatically determine when a process is associated with a terminated request or is it a fuzzy exercise (like watching "top" for awhile)? Do you use /Control_Panel/DebugInfo? When you find it, is it sufficient and safe to just kill it?
--kyler
I'm not sure if there is a way to know if the request has been terminated, but if you could killing the thread should work. I think Zope creates new threads until the maximum set in the start script is reached. If one was killed I would assume that Zope would just start up another one the next time it is needed until the maximum is again reached. This would greatly reduce the problem I agree. -Brian
Brian Brinegar wrote at 2003-7-17 11:10 -0500:
I work with a Zope deployment at a University. Each school has a folder within the Zope deploy where they have complete control. We allow each student, staff, and faculty member to have their own personal folder.
One of the problems with this is that users can write a script which loops indefinitely.
We solve such problems (mostly) by separating production, quality test and development to different Zope instances. We use CVS and ZSyncer to synchronize between the various instances. Dieter
participants (4)
-
Brian Brinegar -
Chris McDonough -
Dieter Maurer -
Kyler Laird