[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 8:21 PM, John Todd wrote:

>
> 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.

I suppose it would take a Digium response on this to be sure, but my  
understanding of Asterisk from back when I was first installing it  
(haven't cared since and it was awhile ago) is that it is very  
dependent upon the zaptel timer. It will work without it but all its  
timing will be screwed up, hence the ztdummy module.  Again, this may  
not be true (anymore).

>   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.

As an aside note to this general discussion, it would be nice if  
asterisk (or the startup script, whichever) gave a lot more  
information about what is going on when Asterisk starts.  I agree it  
is a nice to have all your SIP, IAX, etc. lines still work if  
something is screwy with your Zaptel hardware, but it would also be  
really nice to have asterisk report to the startup console (and not  
just the logging console which you almost never see at startup) when  
something bad happens.  More than once I have started up Asterisk and  
have it report an "OK" launch only to find out that it couldn't  
communicate with Zaptel for some reason and decided to quietly (from  
my perspective) ignore all zap channels. Perhaps what would be better  
is...

>   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.

... to invert the command line option.  Provide a command line option  
(and by proxy for init.d startup systems an option in /etc/sysconfig/ 
asterisk) that is the equivalent to a "--paranoid".  When that option  
is present Asterisk either logs to the startup console any errors that  
might make you question the sanity of your Asterisk box or possibly  
prevent asterisk from starting up.  Again something like my  
referencing zaptel channels in zapata.conf but no Zaptel hardware/ 
driver available would fall into this option.  I would instantly turn  
this option on as it would save me many headaches thinking Asterisk  
started fine only to find out half an hour later that it actually  
didn't.

Possibly some combination of options like by default Asterisk will  
print out any startup ERROR messages to the startup console and  
provide --quiet-startup to override.  Then also provide a --paranoid- 
startup or equivalent to prevent startup  if there are any possible  
show-stopping errors during startup.

This does not fully solve some of the issues, but it might alleviate  
some of the headaches.  Generally my first action when trying to debug  
why something is screwy with Asterisk after a power outage or other  
system downtime is to 'service asterisk stop', 'service asterisk  
start', so I would then see any error messages on the console (with  
the above change that is).

>   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."

Agreed, but we should probably at the very least find a way to get  
Asterisk to spit out some messages at startup so I know (when I am  
there working on it) what needs to be fixed, or what isn't working  
right now to tell others.

Daniel

> JT