Cherrypy Process restarting

[Joseph Tate]

I'm building a CherryPy application that will need to restart itself
because it can update its own code (as well as the cherrypy code it
depends on).

Talking with Robert Brewer in IRC, we decided that we could build a
signal handler into cherrypy/lib for platforms that support SIGUSR1 and
SIGUSR2 (supporting other signalling protocols on non POSIX systems).
These signals would call exec to restart the entire cherrypy process.
This could eventually replace the two process autoreload mechanism that
is currently implmented.

That said, Robert said I should seek input from Peter Hunt, who
implemented the two process autoreload mechanism to see if there were
specific pitfalls inherant in the above described design that the two
process mechanism avoids. Peter?

For that matter, are there any comments on this approach in general?

[Joseph Tate]

Well, one of the reasons that autoreload was implemented the way it was
is that the open listener socket doesn't get closed immediately, and
there's no real way to wait for it to close. This means that on the
restart the socket is still allocated by the OS, and you get a
socket.error "98, address already in use" that no amount of retrying
will fix.

So, there are a couple of options here. We can sit and wait some
arbitrary amount of time for the socket to actually close before
restarting, we can fork before calling exec (which lets the OS close
the socket during cleanup), or we can cache the socket object somehow
and reuse it in the new execution.

I don't have to tell you that option one sucks. I tried using
SO_LINGER options on the socket, but on Linux at least, it had no
effect. SO_LINGER is supposed to let close() block until it actually
completes or until a timeout.

For option two, if you were using some sort of init script to start the
server and had the PID stored in a pidfile, you would have to rewrite
that pidfile. Doing so in a sufficiently generic way may not be
possible.

Option three seems the best to me, I can set an environment variable
with the file descriptor of the socket, and reinitialize it when the
new process instance comes up.

Joseph

[Robert Brewer]

> Option three seems the best to me. I can set

> an environment variable with the file descriptor
> of the socket, and reinitialize it when the
> new process instance comes up.

Sounds like the best option if you can get it to work.

Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org