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

[Tzafrir Cohen]

On Sat, Apr 05, 2008 at 06:39:10PM -0700, Daniel Hazelbaker wrote:
> 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.

When a Zaptel timing source is available to Asterisk it is used to
synchronize(?) playback and many other things. Or is it just on SIP?

Now, suppose we get a bit smarter, and if a zaptel timing source is not
available, we'll disable that option (note that I'm not sure what it
takes at runtime code-wise. I'm merely speculating).

For anybody with ztdummy problems this may be the ideal failure mode.
But what about someone with a transient Zaptel problems (such as a red
alarm on T1)? After that problem went away, he'll still have some
quality issues (some clicks and such) because Asterisk's reading is not
in sync with his writing (right?).

The latter is much more difficult to trace.

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

Asterisk does provide an extensive lgging facility. Have you niticed
where that code is added? right after initializing the logger, in order
to get those messages logged. 

With th default configuration of Asterisk, /var/log/asterisk/messages is
a handy tool for debugging error.

On my system the mailer has a separate mail.log, mail.warn and mail.err 
log files. You can easily do the same with asterisk with trivial
logger.conf config lines:

# the default:
messages => error,warning,notice

# Add those:
warn    => error,warning
err     => error

One might say that some of Asterisk's error messages are mis-labeled.
I'm sure that after using Asterisk with such a log file you'll be able
to file a number of useful bug reports.

The console is intended for recieving immediate information. Not
after-the-fact log messages. This is also why console messages have no
time-stamp by default (this saves in size and makes the message mor
readable). You normaly "see" the timing, anyway.

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

Use the logs, Luke!

That facility is already in place.


If we add an option half the people who really need it will not be
easily be able to use it (e.g: know where exactly to add it. Or even
know that this is the thing to use). And OTOH, most of the people who'll
use it will be those who add it "just in case". 

One example of a "just in case" is the fact that TrixBox enables only 
the "full" log file (but not the "messages" one. And is also verbose by 
default. Now go and trace what exactly broke Asterisk from that? You can, 
but it takes much longer.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir