summaryrefslogtreecommitdiffstats
path: root/mkdocs.yml
diff options
context:
space:
mode:
authorPierre de La Morinerie <kemenaran@gmail.com>2018-02-16 06:17:03 +0530
committerChristopher Speller <crspeller@gmail.com>2018-02-15 16:47:03 -0800
commitb112747de76f9c11c4d8083207049fac6e435019 (patch)
tree119e5bf42bbfd28d36c14378344e4c3061add808 /mkdocs.yml
parent2930766c65fe5703e7bbec45c605cc7fc4188a66 (diff)
downloadchat-b112747de76f9c11c4d8083207049fac6e435019.tar.gz
chat-b112747de76f9c11c4d8083207049fac6e435019.tar.bz2
chat-b112747de76f9c11c4d8083207049fac6e435019.zip
Send systemd READY notification (#8296)
Currently, when starting Mattermost programmatically, it's hard to tell when the server is actually ready to receive network connections. This isn't convenient for monitoring (the systemd service status is "running" although the server is still booting), nor for programatic use (where a script would need to know when the server is ready to perform further actions). To improve this, systemd allow processes to tell when they started successfully. The launcher waits for this notification before reporting the service as successfully launched. The way processes notify systemd is by sending a `READY=1` string over a standard unix socket, whose path is provided in an environment var. The systemd service is then told to expect this notification: ```diff [Service] -Type=simple +Type=notify ExecStart=/home/vagrant/go/bin/platform ``` Now, when starting the server, systemd will actually wait for the server to be ready before returning the control to the shell. Additionally, during this time, querying the server status with `service mattermost status` will report the service as "activating" – before transitioning to "running" when the server is ready.
Diffstat (limited to 'mkdocs.yml')
0 files changed, 0 insertions, 0 deletions