Using qp 1.9.1, I on occasion get the following traceback from qp
when stopping a site:

Traceback (most recent call last):
   File "/usr/local/bin/qp", line 102, in 
     site.stop_durus()
   File "/usr/local/lib/python2.5/site-packages/qp/lib/site.py", line
425, in stop_durus
     unlink(self.get_durus_pidfile())
OSError: [Errno 2] No such file or directory: '[edited].durus.pid'

It looks like a race condition between the durus process removing the
pidfile and qp also trying to remove the pidfile. Perhaps the unlink
call in Site.stop_durus should be wrapped with a try: clause?

Also, I've got another odd problem that occurs on occasion related to
the pid file. If the durus server gets killed by a signal (say
SIGTERM), its pidfile gets left around. It won't get cleaned up with
a later call to stop_durus (say via qp) since is_durus_running blocks
that action.

What can then happen is if you reboot the OS and happen to get a non-
durus long running process with the pid of the previous one that
exited on SIGTERM, is_durus_running will block durus from starting.
You have to remove the .durus.pid file by hand to correct the situation.

This would seem to be an extremely unlikely occurrence but I've had
it bite me twice now.

Would a reasonable fix be to add a call to wait_for_server in
is_durus_running to verify that the process running with that PID is
really the durus server we think it is?

Dave

------
David K. Hess
Verscend Technologies, Inc.
dhess@verscend.com
214-684-5448