Re: Dynamic Reconfiguration

On Thu, May 16, 2002 at 06:03:34PM -0400, William P LePera wrote:
> I am seeing a strange behavior with dynamic reconfiguration, and am curious
> if anyone else has seen it or knows a way around it.

heh, unfortunately, it isn't strange.

> If I change the config to add another console, then send SIGHUP to the
> master process, another conserver process is spawned, for a total of three.
> I would have expected the new console to be added to the existing child
> process, but that does not appear to be the case.  At this point, if
> conserver is brought down and back up again, I get two process, and the
> child process has all 9 consoles on it.

yep.

> Is this the way it's supposed to work?  If I add consoles in batches and
> send SIGHUP after each batch, will I always get a new conserver process for
> each SIGHUP?  Is there a way around this which doesn't involve killing
> conserver and restarting it?

nope.  it's the way it was designed.  conserver will fork off as many
processes as necessary to handle the new consoles, so if you add 1-16,
you get one new process, 17-32, you get two, etc (with the default 16
per process).  if you've been adding them slowly over time and have a
lot of processes and want the consoles managed by less processes,
you're only choice is to do a full restart.

the reason for designing it to work this way is simple: there is no
communication between the conserver processes.  there is just the
forking of sub-processes and relaying of the clients.  because of this,
each sub-process ends up rereading the config file and operating
independently of the master process.  since the master needs to know
which sub-process is managing which consoles, having an existing
process use one of it's free slots to manage a console is troublesome.
and, if you delete a console, which gives a semi-random sub-process a
free slot, you end up with multiple sub-processes with free slots and
no way of coordinating which processes control the new consoles.
yikes...the more i go on the uglier it gets, but you get the idea.

yes, if there was some sort of communication between the processes,
this could all be avoided and the master process could reread the
config file, figure out the new consoles, send messages instructing
sub-processes to add the console definitions to a free slots, and new
processes wouldn't have to be spawned.  it was a tradeoff between
implementing an array of message passing (uni-directional, at least) or
just using the already-existing forking code.  i took the easy way out
and just extended the existing philosophy in the code.

so, yes, it's not ideal to add just one or two consoles at a time (and
it would be nice if it was handled better)...but at least you can!

Bryan