I am starting a server process using "twistd -oy" (don't save state;
application is described by Python source). If all is well, the server is
started in the background. However, if all is not well, I'd like to detect
that startup failed.
The particular scenario that I'm using is testing a server using a test
framework that does HTTP requests. Before the tests are run, the server is
started and it tries to bind to a fixed port. If there is still an old
instance of the server running, the bind will fail and any requests made will
be handled by the old instance instead. That will lead to invalid test
I worked around it currently by waiting for 3 seconds (probably sufficient
time to try the binding) and then checking if the process of which the ID
stored in "twisted.pid" is still running. However, there is no guarantee that
3 seconds is always enough time for the server to have bound the port. So I'm
wondering if there is a reliable and elegant way of solving this.
One approach would be to check which process has bound a particular port. I'm
running this server on Linux and the "netstat" command line tool has access
to the right information, but not in an easily parseable format. I guess the
same info can be found in /proc somehow, but are those files guaranteed to
stay compatible with newer kernels?
Another approach would be to check in advance if something is listening on
that particular port, but between the time this check is done and the time
the server tries to bind, some other process might have grabbed the port.
In any case, the port already being bound is just one of the reasons why the
startup might fail; I'd prefer to have a way to detect startup failures for
other reasons as well.
One question is when exactly "startup" is finished. For my purpose, the moment
the reactor is running would be the moment I consider startup to be
successful. Maybe I can write a file somewhere to explicitly signal that, but
that's a bit messy (where to put it? is the server process allowed to write
there? who cleans up the file?).
Maybe it would be useful to have twistd (optionally) wait until the reactor is
running before returning. I don't want the test script to rely on a patched
version of Twisted, so this would only be an option if it would make sense to
integrate such a feature into Twisted itself.
Have you encountered this problem as well? And if so, how did you deal with