Mailing List Archive

reread config
I've gone part way through making a patch for rereading the config
file on a USR1 signal. Then I looked at the readcfg routine.
Lots of dynamically allocated stuff. So, I thought, before I go
any further, I'd ask whether anybody else has already done this
before I start trying to redo dynamic memory, etc.
Doug
Re: reread config [ In reply to ]
I don't know if anyone else has tried, but I've definately thought about it for
quite a while. As you've seen, it's not easy. What's really a bummer is that
there's a statically allocated array that holds all the really interesting
stuff. So, each child will have to re-read the configuration file or there
needs to be some way for them to receive "updates" of sorts or told to not
manage certain consoles or whatever. See, the real question is, if someone
adds a console to a .cf file somewhere in the middle, everything gets shifted.
The processes, if spawned newly, would each manage a new console and lose one
as well (each get a set in the order of the .cf file). Those connected to
consoles have TCP connections with particular child processes. Do you drop all
connections and have things re-read and have the children know what group
they're supposed to manage or do you feed a message to the children
saying "don't manage this any more" and "manage this now" or do you spawn a new
child for the newly added consoles and let the new child control all the new
consoles. It's kind of a horrid problem.

If you really want to attempt it (and I think it would be wonderful), I'd love
to know what ideas you have (and maybe the list in general) so that we can all
punch holes in any ideas...it's something that I think requires a whole lot of
thought, because of the underlying architecture. One thought is that
underlying architecture needs to just change, so that this is easier. I wish I
had some basic ideas on how to improve things, but I haven't had a chance to
think about anything but the pitfalls...hence my paragraph above. Anyway, good
luck, and please keep at least me informed...it's a challenge I'd love to see
conquered (and helping with the idea/planning phase is something I'd love to
do).

Bryan

Quoting Doug Hughes <doug@gblx.net>:
> I've gone part way through making a patch for rereading the config
> file on a USR1 signal. Then I looked at the readcfg routine.
> Lots of dynamically allocated stuff. So, I thought, before I go
> any further, I'd ask whether anybody else has already done this
> before I start trying to redo dynamic memory, etc.
> Doug
Re: reread config [ In reply to ]
On Thu, 26 Apr 2001, Bryan Stansell wrote:

> I don't know if anyone else has tried, but I've definately thought about it for
> quite a while. As you've seen, it's not easy. What's really a bummer is that
> there's a statically allocated array that holds all the really interesting
> stuff. So, each child will have to re-read the configuration file or there
> needs to be some way for them to receive "updates" of sorts or told to not
> manage certain consoles or whatever. See, the real question is, if someone
> adds a console to a .cf file somewhere in the middle, everything gets shifted.
> The processes, if spawned newly, would each manage a new console and lose one
> as well (each get a set in the order of the .cf file). Those connected to
> consoles have TCP connections with particular child processes. Do you drop all
> connections and have things re-read and have the children know what group
> they're supposed to manage or do you feed a message to the children
> saying "don't manage this any more" and "manage this now" or do you spawn a new
> child for the newly added consoles and let the new child control all the new
> consoles. It's kind of a horrid problem.
>
hmm. yeah. that's sort of what I feared.

> If you really want to attempt it (and I think it would be wonderful), I'd love
> to know what ideas you have (and maybe the list in general) so that we can all
> punch holes in any ideas...it's something that I think requires a whole lot of
> thought, because of the underlying architecture. One thought is that
> underlying architecture needs to just change, so that this is easier. I wish I
> had some basic ideas on how to improve things, but I haven't had a chance to
> think about anything but the pitfalls...hence my paragraph above. Anyway, good
> luck, and please keep at least me informed...it's a challenge I'd love to see
> conquered (and helping with the idea/planning phase is something I'd love to
> do).
>

well, I don't really have time to do a significant amont of work on it
right now, and it seems like that is what would be required. However, I
will noodle on it for a while. Back burner on slow simmer.
conserver consomme.

The thing I really don't want is something that will drop all existing
connections. We've got all the consoles hanging off cisco async
boards requiring securid authentication, so dropping and restarting
all those connections would require a significant amount of manual
intervention. So, it's an interesting problem. I haven't really looked
at it in great depth. I was wondering if there might be a way to lookup
entries as the cf is parsed, and only delete ones that weren't found
and deallocate or add new ones that were found.

Doug
Re: reread config [ In reply to ]
Quoting Doug Hughes <doug@gblx.net>:
> well, I don't really have time to do a significant amont of work on it
> right now, and it seems like that is what would be required. However,
> I
> will noodle on it for a while. Back burner on slow simmer.
> conserver consomme.

Cool. That's what I've been doing for a few years now...it's such a nasty
problem to fix "right" that it seems to never go anywhere. My final answer was
to rewrite the whole thing so it could do stuff like reread the config file.
Well, hopefully you're burner is on a little higher than mine (or more
effecient or something).

> The thing I really don't want is something that will drop all existing
> connections. We've got all the consoles hanging off cisco async
> boards requiring securid authentication, so dropping and restarting
> all those connections would require a significant amount of manual
> intervention. So, it's an interesting problem. I haven't really looked
> at it in great depth. I was wondering if there might be a way to
> lookup
> entries as the cf is parsed, and only delete ones that weren't found
> and deallocate or add new ones that were found.

Ditto...I really want it to be dynamic and transparent to everything.

Bryan
RE: reread config [ In reply to ]
My recommendation for avoiding the shifting of consoles in the middle of
being used is to have conserver refuse to add them for a config reread if it
detects that a change in the .cf file happens in between existing consoles.

If the changes happen so that they can be tagged "on the end" of the list of
consoles without shifting everything around or disconnecting anything, that
would be better than no dynamic ability or a cold restart which makes the
changes take effect, but disconnects all.

Ernie


> -----Original Message-----
> From: users-admin@conserver.com [mailto:users-admin@conserver.com]On
> Behalf Of Bryan Stansell
> Sent: Thursday, April 26, 2001 8:40 PM
> To: users@conserver.com
> Subject: Re: reread config
>
>
> Quoting Doug Hughes <doug@gblx.net>:
> > well, I don't really have time to do a significant amont of work on it
> > right now, and it seems like that is what would be required. However,
> > I
> > will noodle on it for a while. Back burner on slow simmer.
> > conserver consomme.
>
> Cool. That's what I've been doing for a few years now...it's
> such a nasty
> problem to fix "right" that it seems to never go anywhere. My
> final answer was
> to rewrite the whole thing so it could do stuff like reread the
> config file.
> Well, hopefully you're burner is on a little higher than mine (or more
> effecient or something).
>
> > The thing I really don't want is something that will drop all existing
> > connections. We've got all the consoles hanging off cisco async
> > boards requiring securid authentication, so dropping and restarting
> > all those connections would require a significant amount of manual
> > intervention. So, it's an interesting problem. I haven't really looked
> > at it in great depth. I was wondering if there might be a way to
> > lookup
> > entries as the cf is parsed, and only delete ones that weren't found
> > and deallocate or add new ones that were found.
>
> Ditto...I really want it to be dynamic and transparent to everything.
>
> Bryan
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
>
RE: reread config [ In reply to ]
RE: reread configYes, that should go along with the reread. It should read
the files and act like the copies in memory are all that exist until the
next reread is requested.

Ernie

-----Original Message-----
From: Chris Fowler [mailto:ChrisF@computone.com]
Sent: Monday, April 30, 2001 1:32 PM
To: 'Ernie Oporto'
Subject: RE: reread config


It seems that for some reason, conserver holds open the config file. I
would prefer that it be closed after reading.

Chris



-----Original Message-----
From: Ernie Oporto [mailto:Ernie.Oporto@viragelogic.com]
Sent: Monday, April 30, 2001 10:18 AM
To: users@conserver.com
Subject: RE: reread config



My recommendation for avoiding the shifting of consoles in the middle of
being used is to have conserver refuse to add them for a config reread if
it
detects that a change in the .cf file happens in between existing
consoles.

If the changes happen so that they can be tagged "on the end" of the list
of
consoles without shifting everything around or disconnecting anything,
that
would be better than no dynamic ability or a cold restart which makes the
changes take effect, but disconnects all.

Ernie



> -----Original Message-----
> From: users-admin@conserver.com [mailto:users-admin@conserver.com]On
> Behalf Of Bryan Stansell
> Sent: Thursday, April 26, 2001 8:40 PM
> To: users@conserver.com
> Subject: Re: reread config
>
>
> Quoting Doug Hughes <doug@gblx.net>:
> > well, I don't really have time to do a significant amont of work on it
> > right now, and it seems like that is what would be required. However,
> > I
> > will noodle on it for a while. Back burner on slow simmer.
> > conserver consomme.
>
> Cool. That's what I've been doing for a few years now...it's
> such a nasty
> problem to fix "right" that it seems to never go anywhere. My
> final answer was
> to rewrite the whole thing so it could do stuff like reread the
> config file.
> Well, hopefully you're burner is on a little higher than mine (or more
> effecient or something).
>
> > The thing I really don't want is something that will drop all existing
> > connections. We've got all the consoles hanging off cisco async
> > boards requiring securid authentication, so dropping and restarting
> > all those connections would require a significant amount of manual
> > intervention. So, it's an interesting problem. I haven't really looked
> > at it in great depth. I was wondering if there might be a way to
> > lookup
> > entries as the cf is parsed, and only delete ones that weren't found
> > and deallocate or add new ones that were found.
>
> Ditto...I really want it to be dynamic and transparent to everything.
>
> Bryan
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
>

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users