[asterisk-dev] [svn-commits at lists.digium.com: [svn-commits] dhubbard: branch 1.4 r112689 - /branches/1.4/main/asterisk.c]

[Daniel Hazelbaker]

On Apr 4, 2008, at 10:24 AM, John Todd wrote:

> At 5:30 AM -0500 4/4/08, Kevin P. Fleming wrote:
>> I would support a command line option to skip this check, if the user
>> wants to specify it so that they can run Asterisk for some other
>> (non-normal usage) purpose since they believe they know what they  
>> are doing.
>>
>
>
> I would disagree here, strongly.
>
> Let's take the case of "power went out".  I've lost all my T1
> equipment, and the SLC down the hall is also off the air after an
> extended outage.  Power comes back on, my Asterisk systems reboot.
> The SLC is still going through test modes, which they do for a few
> minutes.  But no sync on the T1's!  So, my Asterisk system fails to
> come up, and now I have to manually intervene, either with the arcane
> command line option, or remove zaptel (!!!) and start my other
> services that don't rely on timing.

What about providing the command-line option to bypass the requirement  
of a valid timing source and if it is not given then Asterisk starts  
but waits to fully initialize until the timing source (whatever it is)  
becomes available.

e.g.

./asterisk
*** Warning: Waiting for timing source before starting asterisk (run  
with --bypass-timing-source to skip)...
^C
./asterisk --bypass-timing-source

Wether not it could be implemented I don't know, but that would solve  
the problem of asterisk re-starting before the timing is available but  
still allow one to override it and force it to start immediately. It  
is still a little unfriendly, but would provide the user with instant  
feedback on how to get around the problem.

Daniel

> JT