On 8/21/07, <b class="gmail_sendername">Maarten ter Huurne</b> <<a href="mailto:maarten@treewalker.org">maarten@treewalker.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>I am starting a server process using "twistd -oy" (don't save state;<br>application is described by Python source). If all is well, the server is<br>started in the background. However, if all is not well, I'd like to detect
<br>that startup failed.<br><br>The particular scenario that I'm using is testing a server using a test<br>framework that does HTTP requests. Before the tests are run, the server is<br>started and it tries to bind to a fixed port. If there is still an old
<br>instance of the server running, the bind will fail and any requests made will<br>be handled by the old instance instead. That will lead to invalid test<br>results.<br><br>I worked around it currently by waiting for 3 seconds (probably sufficient
<br>time to try the binding) and then checking if the process of which the ID<br>stored in "twisted.pid" is still running. However, there is no guarantee that<br>3 seconds is always enough time for the server to have bound the port. So I'm
<br>wondering if there is a reliable and elegant way of solving this.<br><br>One approach would be to check which process has bound a particular port. I'm<br>running this server on Linux and the "netstat" command line tool has access
<br>to the right information, but not in an easily parseable format. I guess the<br>same info can be found in /proc somehow, but are those files guaranteed to<br>stay compatible with newer kernels?<br><br>Another approach would be to check in advance if something is listening on
<br>that particular port, but between the time this check is done and the time<br>the server tries to bind, some other process might have grabbed the port.<br><br>In any case, the port already being bound is just one of the reasons why the
<br>startup might fail; I'd prefer to have a way to detect startup failures for<br>other reasons as well.<br><br>One question is when exactly "startup" is finished. For my purpose, the moment<br>the reactor is running would be the moment I consider startup to be
<br>successful. Maybe I can write a file somewhere to explicitly signal that, but<br>that's a bit messy (where to put it? is the server process allowed to write<br>there? who cleans up the file?).<br><br>Maybe it would be useful to have twistd (optionally) wait until the reactor is
<br>running before returning. I don't want the test script to rely on a patched<br>version of Twisted, so this would only be an option if it would make sense to<br>integrate such a feature into Twisted itself.<br><br>
Have you encountered this problem as well? And if so, how did you deal with<br>it?<br><br>Bye,<br> Maarten<br><br>_______________________________________________<br>Twisted-Python mailing list<br><a href="mailto:Twisted-Python@twistedmatrix.com">
Twisted-Python@twistedmatrix.com</a><br><a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a></blockquote><div><br><br>Yes, I've encountered this problem before. And yes, I initially did the same thing as you, by waiting a hardcoded time. But eventually I got tired of this race condition, and that it doesn't detect when the server failed to start. What I'm doing right now for my non-unit functional testing is running a bash script which:
<br><br>- make sure twistd isn't running using ps: ps aux | grep twistd | grep -v grep<br>- start up the app in non-daemon mode, send its output to the console and to a file:<br> twistd -noy my-app.tac | tee server.log
&<br>- poll the server.log by grep'ing for a string I print from my app when the app is completely started<br>- launch the tests against the running server (I think I'm using mechanize right now for web client library)
<br><br>This works for me in my development environment, on Linux.<br><br>Cheers,<br>Christian<br> <br></div><br></div>