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

[John Todd]

At 5:30 AM -0500 4/4/08, Kevin P. Fleming wrote:
>Tzafrir Cohen wrote:
>
>>  A. Zaptel started, but module provideing the ting hasn't yet (either
>>  ztdummy, or ztcfg was not run for a different module). This is indeed a
>>  configuration error. But would be mostly harmless till now.
>>
>>  B. Timing from a E1/T1 card that is not in sync but is listed to give
>>  timing. It should be possible for me to restart Asterisk when the cable
>>  to the card is disconnected or when the telco's side is misconfigured.
>
>As you can see from the many threads on asterisk-users where lack of an
>available timing source causes problems that the users can't reasonably
>debug (many of those threads you even help the users in, thanks!), I
>think we need to err on the side of not attempting to run Asterisk when
>the timing source is not operating but we've been told to use it.
>
>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.

This introduces a failure mode that is variable, meaning that an 
unexpected external set of circumstances (which is quite common, by 
the way) will cause a failure in operation requiring manual restart. 
This type of failure will only evidence itself under the worst 
possible circumstances, and users who "fire and forget" Asterisk 
won't have any idea what is going on.

I would suggest that if there is a desire to change functionality, 
then an enhanced error report might be generated (a few lines of 
"***" surrounding the message to make it stand out) or when Asterisk 
in interactive mode is entered that a warning message is printed upon 
connection.  Perhaps both.

I understand that not having timing causes "support issues". 
However, not starting Asterisk at all based on a common failure mode 
seems to be overzealous and operator-unfriendly.

JT