1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
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
|
