# Hatta survives runit TERM signal

Hatta seems to have at least two threads when running under runit (a clone of DJB's dæmontools). When runit sends hatta a TERM signal, only the first hatta thread exits — the second one survives and sits on the TCP port, making it impossible to restart hatta without manually killing the surviving thread.

Could hatta possibly propagate signals to its child threads?

## Discussion

For the local, standalone server Hatta uses Werkzeug's WSGI server, which actually starts a second Python process to run wsgiref web server, and keeps monitoring the source file for changes in the original process – this way it can reload the program when something changes. This is very convenient for development, which is the main use for the Werkzeug server. I suppose I can use wsgiref directly, and for debugging use a separate script that would start it with Werkzeug…

By the way, you can use any WSGI web server, starting with wsgiref from Python's standard library, through Cherrypy's server, Flup adapters, to fullblown servers like Nginx, Lighttpd, Cheroke or Apache. For example, to use Cherrypy's excellent server, you would need something like this:

import hatta
config = hatta.WikiConfig(
pages_path='/path/to/pages/', # XXX Edit this!
cache_path='/path/to/cache/', # XXX Edit this!
)
host, port = config.interface or 'localhost', int(config.port)
wiki = hatta.Wiki(config)
from cherrypy import wsgiserver
server = wsgiserver.CherryPyWSGIServer((host, port),
[('', wiki.application)])
try:
server.start()
except KeyboardInterrupt:
pass


This is especially recommended if you want to run a public wiki, but don't want to install a web server specially for that – wsgiref is not really suited for production use, Cherrypy is much more so. – Radomir Dopieralski

## Fixed

The current development version uses wsgiref alone – so it doesn't create any long-running threads or processes.

Fixed Bugs