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

[John Todd]

At 3:59 PM -0700 2008/4/4, Daniel Hazelbaker wrote:
>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.


I see where you're coming from, but there are still two problems with 
the command-line option scenario:

  1) Most users will never find out about Asterisk's failure to start 
without zap timing until it bites them an an operationally 
inconvenient way (read: "Your [job/consulting contract] may depend on 
Asterisk working in a lights out situation.")

  2) While having zap timing is probably necessary for many things, it 
is unnecessary for most things.  Why should startup even pause (or 
worse, fail) if zap timing isn't available?  All the other services a 
box provides (other than MeetMe, IAX2 trunking, and what else?) will 
still work fine.

   The fact that my T1 provider sucks sometimes should not mean that 
Asterisk wedges itself into uselessness as the default behavior after 
restart.   At 3:00 AM, on the ssh client on my Treo, I do NOT want to 
be trying to remember why Asterisk won't start on the machine in a 
different continent.  If there's no zap timing, that's fine - but * 
better start up to serve my SIP endpoints, my voicemail, my whatever.


   Let's look at it this way: What is a "default" setting for?  A 
"default" setting is that which most people would expect to be turned 
on, because that setting gives the most common or expected behavior 
on a given program.  In it's most simplistic terms: Asterisk NOT 
starting is NOT the expected behavior.  This by itself is a good 
enough reason, I believe, to reverse what apparently was changed.  If 
I have to add this new command-line thing to ALL my Asterisk 
installations, then it pretty much should be a default.  Let's ask a 
new user this question:

   "Would you want minor driver inconsistencies to cause Asterisk to 
not start at all, or would you rather that Asterisk starts, prints 
warning messages, but then continues to operate as best it can given 
that some applications will not work correctly?"

   I think I know the answer to that question, and the answer is 
"Well, I'd rather that Asterisk starts up and does whatever it can."

JT