1. 16 Feb, 2018 1 commit
    • Pierre de La Morinerie's avatar
      Send systemd READY notification (#8296) · b112747d
      Pierre de La Morinerie authored
      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:
      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.
  2. 14 Feb, 2018 1 commit
  3. 12 Feb, 2018 2 commits
    • Derrick Anderson's avatar
      revert master changes · c209e445
      Derrick Anderson authored
    • Pierre de La Morinerie's avatar
      Add tests for the `platform server` command (#8231) · 07fd7aee
      Pierre de La Morinerie authored
      * Cleanup app state on initialization error
      When returning an initialization error, the app state was not cleaned
      up. This is especially visible during tests, as `appCount` is not
      decremented, and makes the new app initialization fail.
      * Test the `platform server` command
      As the `platform server` command only exits when interrupted by
      a signal, it is not possible to test it as the other cobra
      commands. Instead we directly test the actual command function.
      The internal command handler is slighly refactored to take
      a channel in argument, and registers it as the signal handler.
      Nothing very different—except than controlling this channel
      from the outside allows the test to send the system signal
      itself, thus preventing the server to run forever.