Signal Handling

The helper.Controller class will automatically setup and handle signals for your application.

When the Controller extended application starts, helper registers handlers for four signals:

Signals received call registered methods within the Controller class. If you are using multiprocessing and have child processes, it is up to you to then signal your child processes appropriately.

Handling SIGTERM

In the event that your application receives a TERM signal, it will change the internal state of the Controller class indicating that the application is shutting down. This may be checked for by checking for a True value from the attribute Controller.is_stopping Controller.is_stopping. During this type of shutdown, Controller.cleanup will be invoked. This method is meant to be extended by your application for the purposes of cleanly shutting down your application.

Handling SIGHUP

The behavior in HUP is to cleanly shutdown the application and then start it back up again. It will, like with TERM, call the Controller.stop method. Once the shutdown is complete, it will clear the internal state and configuration and then invoke Controller.run.

Handling SIGUSR1

If you would like to reload the configuration, sending a USR1 signal to the parent process of the application will invoke the Controller.reload_configuration method, freeing the previously help configuration data from memory and reloading the configuration file from disk. Because it may be desirable to change runtime configuration without restarting the application, it is advised to use the Controller.config property method to retrieve configuration values each time instead of holding config values as attributes.

Handling SIGUSR2

This is an unimplemented method within the Controller class and is registered for convenience. If have need for custom signal handling, redefine the Controller.on_signusr2 method in your child class.