1 The effect of "disorder reconfigure"
2 ====================================
4 This is current rather vaguely defined and implemented. This file
5 will lay out what you can and cannot change over a reconfigure. Any
6 other changes will require a full server restart.
8 The situation is gradually improving; this file tracks the current
11 * Options that might have to remain the same across restart
13 Arguably if there is anything in this section then that's a serious
16 ** alias (enforced at reload only)
18 This defines how aliases are inserted into the track database. Need
19 to think about how changing it will affect things.
21 ** namepart (enforced at reload only)
23 Probably affects alias construction.
25 ** stopword (enforced at reload only)
27 The search database will have to be rebuilt from scratch.
29 ** user (enforced at reload only)
31 All the files will be owned by the wrong user!
33 ** Alias, search database, etc
35 Rescan can regenerate aliases and the search and tag databases but we
36 rather assume that they are either empty or good. Therefore we need
37 to store anything that can affect these values and erase them if they
40 The solution is a global pref _dbparams which contains the hash of the
41 alias, stopword and namepart data.
43 * Options that must remain the same across reload
45 Some things will just require a restart. We should either enforce
46 this (refusing to accept modified configurations that purport to
47 change them) or explicitly ignore it.
49 ** home (enforced at reload)
51 We absolutely cannot accept changing our state directory.
53 ** lock (generates a deprecation warning)
55 Liable to be removed anyway.
57 ** nice_speaker (generates a warning)
59 You can't renice a running speaker to make it less nice (and we don't
60 try to make it more nice).
62 * Options that ought to be changable across reload but aren't
64 These options need some work somewhere to be changeable just by a
69 The main server will cope fine with this changing. The speaker will
70 ignore the change however.
74 The speaker will ignore the change.
78 The speaker will ignore the change.
82 If the set of collections change we ought to initiate a rescan.
86 The speaker will ignore the change.
90 The speaker will ignore the change.
94 The speaker will ignore the change.
98 The speaker will ignore the change.
102 The speaker will ignore the change.
106 The speaker will ignore the change.
108 * Options that can be changed across reload
110 These options can be changed at reload and it should just work.
112 ** authorization_algoritm
130 Wouldn't affect an already-running rescan, but reload already cancels
131 and restarts the underway rescan anyway.
147 * Options that can change, but with a caveat
149 These options can be changed at reload but there is some caveat about
150 this (which ought to be documented, and in some cases is).
154 Plugin path. You can change the plugin path but an already-loaded
155 plugin may stay loaded.
157 ** cookie_key_lifetime
159 Only affects subsequently generated keys - cannot shorten (or extend)
160 the lifetime of the current key.
162 ** cookie_login_lifetime
164 Only affects subsequently generated cookies - cannot shorten (or
165 extend) the lifetime of already-generated cookies.
169 The history might not shorten until it's next written.
173 Won't affect running players or decoders.
177 Won't shrink the queue.
181 Won't affect already-computed lengths.
183 * Implementation Considerations
185 A likely change is that the speaker will be created on demand and
186 stopped when idle. Some changes will still be handled via SM_RELOAD
187 but others may require the speaker to quit and restart.