[Asterisk-Users] Compiling while * is running

[Steven Critchfield]

On Fri, 2004-01-30 at 13:26, David Gomillion wrote:
> Rob Fugina wrote:
> [snip]
> >> Is there a way to safely compile while * is running, so that I can
> >> minimize down time of the server?
> >
> > Seg faulting compiles usually indicate a memory problem on the
> > machine. Not lack of size, but bad memory, badly seated memory,
> > etc...  There's no reason asterisk running, or the drivers being
> > loaded, should
> > cause a compile to seg fault.
> >
> I don't agree.  When first learning to program, my programs segfaulted all
> of the time, regarless of what machine I was on.  Often, it was doing
> something stupid, like trying to replace a file that was in use, etc.

You apparently still have quite a bit more to learn. If you read the
first line quoted, you will see that it is the compiling that is a
problem. At no time during compile is the application you are compiling
actually executed. Only gcc and it's helpers should be executed. Gcc is
notorious for finding bad memory as it sprawls out over large sections
and is sensitive to bits flipping around. If Asterisk was segfaulting,
then there may be a question as to whether asterisk behaved differently
under load(timing issues) or if it was still bad memory.

> On my machine, compiling took ~2 minutes, for all 3 pieces (zaptel, libpri,
> and asterisk).  To get 5 9's (99.999% uptime), you need to be up for 13.9
> days (check my math... it's been a while).

5 9's is approximately 5 minutes over the course of a year. You couldn't
do this 3 times a year and stay under that time so that is every 4+
months. Also that is assuming that the modules unload and load fine, and
you aren't dealing with any problems getting sync back on any T1 lines.
Really any reload of the modules will put you close to that 5 minutes
per year. Luckily the low level drivers don't change often, and neither
does libpri. So updating and restarting asterisk usually only incurs a
sub 1 minute unavailable period.

> My suggestion: if this downtime is unacceptable for your use, then get an
> identical machine, exactly alike in all ways, including library versions,
> hardware, etc, and compile it on that machine.  Then copy the appropriate
> directories over to your production machine.  Copy the production machine's
> directories to a safe location, stop * and zaptel, copy the new compiled
> things over, then restart * and zaptel.  My guess is that 30 seconds should
> be plenty of time for this change.  Thus, you only need to have been up for
> the last 3.47 days to have 99.999% uptime.

You should really look into bc -l before you speak. 30 seconds over 3.47
days is 99.989 percent uptime. For true 5 9's, you could only spare
2.998 seconds in 3.47 days.

> Either that, or maybe if uptime is so critical, you should have a "hot
> spare" machine on-hand at all times.

Maybe you don't know how long it takes to sync a T1 line. That alone
_can_ take almost a minute. Then the service can come up. If time is
critical, it is probably not a good idea to just upgrade asterisk at a
whim. This is why a previous post to dev by myself showed I'm still
running releases from October and November of last year. Nothing in the
newer releases are needed at this time, and therefore upgrading isn't
important.
-- 
Steven Critchfield  <critch at basesys.com>