Dear Twisted developers,
I am not a developer, and definitely need you advice.
I use Twisted 8.2.0 on Ubuntu 9.04 and on MAX Snow Leopard to set up Buildbot.
One of tests for Buildbot returns an error:
Traceback (most recent call last):
Failure: twisted.internet.error.ProcessTerminated: A process has ended with a probable error condition: process ended with exit code 1
I am getting the same error both on Ubunty and Leopard. Please advice what could be wrong here?
What does it mean “twisted.internet.error.ProcessTerminated: A process has ended with a probable error condition: process ended with exit code 1”?
From: Galina Kistanova
Sent: Tuesday, November 03, 2009 1:23 PM
Subject: twisted.internet.error.ProcessTerminated, exit code 1?
I ran into issue with Twisted, could anybody help me?
I have Twisted 8.2.0 on Ubuntu 9.04.
I run tests for Buildbot 0.7.11p3 and one of the tests completed with the next error:
Traceback (most recent call last):
Failure: twisted.internet.error.ProcessTerminated: A process has ended with a probable error condition: process ended with exit code 1.
Cannot find any information what could cause this.
What “exit code 1 “ means? I tried to stop MsAfee, but this did not help.
Our projects at work include synchronous applications (short lived)
and asynchronous Twisted applications (long lived). We're re-factoring
our database and are going to build an API module to decouple all of
the SQL in that module. I'd like to create that API so both
synchronous and asynchronous applications can use it. For the
synchronous applications I'd like calls to the database API to just
return data (blocking) just like using MySQLdb, but for the
asynchronous applications I'd like calls to the same API
functions/methods to be non-blocking, probably returning a deferred.
Anyone have any hints, suggestions or help they might offer me to do
Thanks in advance,
Thanks for the link info.
I literally just set up Varnish for the first time on my web host, so I
am no pro. However, varnish uses a c like scripting language that can
run regexps on the incoming urls and apply rules to them.
What this means is that we can (as a starting point) choose caching
times for each of those high traffic urls in the varnish script without
touching trac. In the script, we match the front page (with a regexp)
and add a max-cache time to 86400, cache it, etc.
for a great varnish tutorial
By doing that for each of the urls you listed (bar the timeline, which
should be cached for 1 hour or perhaps 30 minutes instead) we will
seriously lighten the load on the database and the webserver, even if
varnish runs on the same machine (as a start).
Every other url (which doesn't have caching set) we could just cache for
30 minutes (perhaps even a day), but only for anon users (no cookies set
>> On 10:41 pm, leyssw(a)ihug.co.nz wrote:
>>> Isn't the simplest option to place a decent reverse proxy between the
>>> webserver and our clients?
>> Possibly so! I gave this a half-hearted attempted a few weeks ago but
>> quickly gave up. If someone who is familiar with configuring such a
>> proxy would like to help out, perhaps we can get something useful up
> Actually, I just looked at Varnish again and remembered that because of
> the way trac sessions work, it's really hard to figure out what may and
> may not be correctly cached. I don't know how to resolve this without
> serious changes to trac itself.
> Twisted-Python mailing list
> End of Twisted-Python Digest, Vol 68, Issue 13
I just set up a script to do a video recording from my iSight using
the pyobjc bridge and the QTKit framework.
This script uses the AppHelper.runConsoleEventLoop (not the
AppHelper.runEventLoop) function to start his main event loop.
I'd like to integrate this script with an existing twisted application
but I have trouble to bring it to work.
The application is a command line based twisted application managed
via AMQP (no user interaction is needed) and started using the twistd
I tried to install the cfreactor but without success as I have to use
Any insights on this?
Thanks in advance,
I am returning to twisted after an extended absence, and was wondering
what the status is with twisted's web framework? Is this an active area
Also looking forward to Twisted9..... :)
Glyph mentioned on python-dev that he was after assistance with
I would like to offer some assistance. I've been developing python
for some time and I have a knowledge of prior C++ async patterns
such as ACE. More currently I have a reasonable knowledge of
protocols such as jabber and so forth.
If there is any way that I might be of assistance, please don't
hesitate to ask.
I have a server-like process that uses twisted. I need it to daemonize
itself and on linux/os x I am simply
using the daemonize function from twistd. This works fine. What about
Windows though....I saw that the
win32 version of twistd doesn't have (unless I am missing it) the ability to
daemonize a process.
Is is simply impossible to daemonize a process on windows? If so, is there
any way to have a child
process on windows ignore SIGINT send to the parent?
Cheers and thanks,
Neither of the below issues will be a problem
Logged in users have a cookie set (I imagine). by default Varnish will not present cached results to users with a cookie, nor will it cache their results for others to see. So the 10% of hits (totally my guess) that are for authenticated users will not be cached. However, some more static assets could be cached regardless of cookies if we so desire.
Varnish has an option to serve an old result out of cache if the server is being non-responsive, it is a feature they call "Grace"
Where this gets hard is that the front page looks different depending on
whether the person requesting it is anonymous or authenticated. If
they're anonymous, various links are not presented. If they're
authenticated, they get the extra links and their username is part of
When I last looked into the performance issues, I found that sometimes
trac appears to block for long periods of time without releasing the
GIL. That seems to be the core of the performance issues, currently.
When it's responding normally, it's perfectly snappy. But, sometimes,
it blocks for 10sec at a time.
My next attempt to improve performance was going to be to run trac in
subprocesses instead of threads. That would hopefully substantially
fix the delay problem.