This is the first step to handle configuration reloading. With those
changes, it is already possible to do so, by sending a SIGUSR2 signal to
the Go server process. The next step would be to watch for changes to
configuration files and call the Restart function of the GoUnicorn
instance.
SIGHUP is catched by the go server and forwarded as-is to gunicorn,
which causes it to restart its workers. However, that does not trigger
a reload of the Django settings, probably because they are already
loaded in the master, before creating any of the worker instances.
SIGUSR2, however, can be used to spawn a new gunicorn master process,
but handling it is a bit trickier. Please refer to Gunicorn's
documentation[0] for details, especially the "Upgrading to a new binary
on the fly" section.
As we are now effectively killing the gunicorn processed launched by the
server, we need to handle some sort of check to make sure it is still
running. That's done by using the already existing healthchecks, making
them useful not only for the application start, but also for its
lifetime. If a check is failed too many times in a given time period,
the gunicorn processed is killed (if necessary) and then restarted.
[0] https://docs.gunicorn.org/en/20.1.0/signals.html
Other relevant links and documentation:
Python library handling the processing swaping upon a SIGUSR2:
https://github.com/flupke/rainbow-saddle/
Golang cannot easily check if a process exists on Unix systems:
https://github.com/golang/go/issues/34396
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Marc 'risson' Schmitt