diff options
Diffstat (limited to 'conf/monitor_athena.conf')
| -rw-r--r-- | conf/monitor_athena.conf | 82 |
1 files changed, 82 insertions, 0 deletions
diff --git a/conf/monitor_athena.conf b/conf/monitor_athena.conf new file mode 100644 index 00000000..68fe65f6 --- /dev/null +++ b/conf/monitor_athena.conf @@ -0,0 +1,82 @@ +// Athena Monitor configuration file. + +////////////////////////////////////////////////////////////////////// +// Some notes about the existence of this file: +// +// tmwa-monitor is unused in its current form, but plans are +// to resurrect it in *some* form. See below for what we do use. +// However, an alternative possibility would be to just install config +// files to integrate with some existing daemon-monitoring tool. +// +// THAT SAID, blindly restarting a server that exited in an unknown +// way is a really great way to get unrecoverable savefile corruption. +// For this reason, we only auto-restart the map server, which only +// persists some unimportant global variables such as high scores. +// Besides, the other servers are stable enough that they rarely crash. +// +// This monitor names three "server"s, but they are just arbitrary. +// This is not enough for the case of multiple worlds, +// and is too much for the case of worlds running as different users. +// +// Currently the server variables are pointing to local shell scripts +// (which are themselves deprecated and print a flashing message), +// which is necessary because the actual servers need to be run inside +// the appropriate dir to read conf and read/write savefiles from/to +// the correct location. This will get better once savefiles get put +// in $localstatedir (i.e. /var), but it's not yet known how that +// should interact with multiple worlds running at the same time. +// +// Likely, however, this will depend on the ability to pass a config +// file as an argument to the servers. +// +// The workdir setting would make a lot more sense if this file was +// installed in $sysconfdir (i.e. /etc) by tmwa's `make install`, +// which is still planned but hasn't happened yet, but makes *less* +// sense if the servers install their config there. +// +// And regardless, we need to allow per-server workdirs, including +// multiple instances, and possible pre/post scripts and exit/signal +// status handlers. But all that seems complicated, leading back to +// "shouldn't we just use an existing daemon manager?". +// +// Alternatively, we could act like an XDG application, which is +// admittedly somewhat odd if you're a daemon, but would at least +// clarify what happens if you run the servers as a user (which we +// do always. When an init script is written, it should run as +// somebody other than root!). +// +////////////////////////////////////////////////////////////////////// +// +// What we actually use instead of tmwa-monitor: +// +// On the main server, we run a tmux session, with one window +// for each server and for each bot. The servers are run directly +// from inside the appropriate directory. +// +// The test server is like the main server without bots, but instead +// of running `tmwa-map` directly, we use the tmwa-map-wrapper script +// from tools/, which restarts the server whenever it exits and merges +// tagged patches from github, except that it does no merges if the +// server exited too quickly after the restart. +// +// On local dev machines, we usually use the `./run-all` script from +// this repo. +// +////////////////////////////////////////////////////////////////////// + + +// Binary to use with message "forked login server". +login_server: ./login-server + +// Binary to use with message "forked char server". +char_server: ./char-server + +// Binary to use with message "forked map server". +map_server: ./map-server + +// Directory in which to run the servers. +// If never set, dynamically computed as $HOME/tmwserver +//workdir: /path/to/tmwa-server-data + +// local settings for this nonserver in this file +import: conf/monitor_local.conf |