HUP handling: a thought

[Alan DeKok]

Nicolas Baradakis wrote:
> I like when the things are simple: edit the config files with your
> favorite editor, and run a command to reload the server. (kill -HUP
> or something else)

  It's nice, but can result in ~1s hiccups when everything gets
reloaded.  There's some code in the server right now to notice that a
config file hasn't changed, so it won't be reloaded.  There's other code
to figure out diff's between old/new config.  It then tries to keep the
*parsed* configuration (e.g. "users" file to data structures), and not
do the parsing again.

  But it's complicated, and it doesn't really work well.

> I think an SQL interface would add a considerable administrative
> overhead. I can easily explain to the sysadmins in my site to copy
> template files to deploy new clients. Explaining to type SQL commands
> seems more difficult.

  Tell them to copy a few template files, and run a script to do it.

> Translating plain text files to SQL has a few issues issues, too. When
> you update a value on a running server, its runtime config is out of
> sync with its config files. Therefore I don't know how we could make
> sure that the "humanly readable" version is relevant or not.

  The "RTA" program I originally pointed to does this by dumping SQL
commands to a file.  When the file is read in, it re-creates the running
configuration.  See also Mercurial's "revlog" format for how to do
high-performance, safe logging of a changing configuration.

  Or, to turn the problem on it's head: Don't touch the existing
configuration.  Instead, write any state to a file (or shared memory).
Exit.  Then, the new server reads the configuration, and bootstraps
itself from the pre-existing state.

  But if all you're doing is adding one realm... why the heck do you
want to reload the other 3000 realms   to add just one?  That doesn't
make sense.  It's an O(N^2) solution to a problem that should be O(1).

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog