handle SIGHUP by reloading your config file #980

New Issue

zooko · 2010-03-04T07:59:25Z

zooko commented

2010-03-04 07:59:25 +00:00

Jacob is writing init scripts for Tahoe-LAFS for Debian, and he asked if it handles SIGHUP by reloading its config file. It currently doesn't. I wonder what all internal state Tahoe-LAFS would have to reset or revisit in order to cleanly "reload its config file". Perhaps the cleanest response to SIGHUP would be to shut down and restart.

zooko added the

labels 2010-03-04 07:59:25 +00:00

zooko added this to the undecided milestone 2010-03-04 07:59:25 +00:00

warner was assigned by zooko

2010-03-04 07:59:25 +00:00

ioerror commented

2010-03-05 05:47:55 +00:00

Tahoe should certainly catch SIGHUP for various things. An example that comes to mind is closing and re-opening log files.

warner commented

2010-03-10 19:50:55 +00:00

there was a lot of state and configuration stuff set up during init, which is why I gave up on SIGHUP-to-reread-tahoe.cfg pretty early. It would involve replacing the Tub, for a start, which means re-registering all Referenceables, replacing the IntroducerClient and the StorageServer.

OTOH, all of this is contained inside the Node instance, and that's just a Service which can be shut down, so maybe we could handle it by doing a top-level stopService, waiting for that to finish, then re-creating the whole Node and starting it back up. This would retain the same pid but replace pretty much everything else.

Logfiles are handled by twisted.python.log, which rotates at some configurable size (1MB, I think). We could route SIGHUP or SIGUSR1 or something to force that, but in my experience the built-in log rotation has always been sufficient.

there was a lot of state and configuration stuff set up during init, which is why I gave up on SIGHUP-to-reread-tahoe.cfg pretty early. It would involve replacing the Tub, for a start, which means re-registering all Referenceables, replacing the IntroducerClient and the StorageServer. OTOH, all of this is contained inside the Node instance, and that's just a Service which can be shut down, so maybe we could handle it by doing a top-level stopService, waiting for that to finish, then re-creating the whole Node and starting it back up. This would retain the same pid but replace pretty much everything else. Logfiles are handled by twisted.python.log, which rotates at some configurable size (1MB, I think). We could route SIGHUP or SIGUSR1 or something to force that, but in my experience the built-in log rotation has always been sufficient.

tahoe-lafs added

code-nodeadmin

and removed

operational

labels 2010-03-25 00:35:43 +00:00

Sign in to join this conversation.