A discussion about properly shutting down Discourse when the host shuts down began with a reference to a previous conversation where it was concluded that running ./launcher stop app should suffice. However, this still requires a separate step. fefrei asked if there’s a way to ensure Discourse always shuts down properly if the system is rebooted on Ubuntu.
omfg suggested that Discourse data is safe since it’s written to the host, and a simple shutdown should be sufficient unless it’s a very busy instance. sam assured that shutdown is safe due to a shutdown sequence triggered by Docker when stopped.
fefrei was concerned about other sysadmins or unattended-upgrades causing issues, but omfg suggested disabling unattended-upgrades and inserting shutdown steps in the system script. However, sam had already addressed this by including the shutdown sequence in the Docker script.
About a year ago, @tobiaseigen asked how to properly shut down Discourse:
The conclusion was that a ./launcher stop app should now suffice. This is great, but it still is a separate step. It won’t help you if another sysadmin shuts down your system, or if unattended-upgrades decides that a reboot is due now.
Is there a way (on Ubuntu) to ensure that Discourse always shuts down properly if the system is rebooted?
Discourse data is written to the host, so whatever has been written, will survive.
Unless you’re on a very busy Discourse instance, I would say you could simply shutdown now.
On a very busy Discourse instance, I’d stop Nginx and DB (in Docker) manually, then shutdown the app and OS. I’d probably make a script that runs these steps and you can do the same (sudo ./shtudown-docker.sh isn’t that hard).
You can disable unattended upgrades (on the OS level).
And you could insert those steps in the system shutdown script.
But Sam said they did that inside of the docker script.