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.