diff options
Diffstat (limited to 'conf/monitor_athena.conf')
| -rw-r--r-- | conf/monitor_athena.conf | 82 |
1 files changed, 0 insertions, 82 deletions
diff --git a/conf/monitor_athena.conf b/conf/monitor_athena.conf deleted file mode 100644 index 68fe65f6..00000000 --- a/conf/monitor_athena.conf +++ /dev/null @@ -1,82 +0,0 @@ -// 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 |