[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 7, 2008, at 3:06 PM, Tzafrir Cohen wrote:

>> The asterisk startup script happily reports "[SUCCESS]" (or other
>> message depending on distro) and you never see a message unless you  
>> go
>> look at the log file.
>
> Right. Those problems occour way after forking into background.

Then more than likely it would be far too difficult to get that  
changed.  My experience is that moving where/when a program forks is  
like pulling teeth (not getting the developers to do it but making it  
work without breaking something else).  I have seen programs, however,  
whose startup scripts wait for a trigger (like the pid file being  
created) before displaying the SUCCESS message.  This gives the forked  
application a chance to display any messages that the user would  
likely be interested in (before closing the stdout fd).

> If there is no config file, should the meetme module just silently  
> fail?
> How will you be able to diagnose this later on?

No, just agreeing with you (I think) that the priority of the current  
log messages is not exactly sane.  (IMHO) The entire config file  
missing is more than likely not a serious error as it is more likely  
that the user didn't want it in the first place (i.e. warning level).   
The meetme config file being unparsable is a serious error.  I know  
meetme is not specifically this way I had picked it at random, others  
like app_amd are.

I don't know that my suggestions are the best ones, just that they are  
suggestions.  Perhaps I am the only one that finds it cumbersome to  
debug issues with asterisk at startup.  I just know there are easier  
ways as other open source projects (such as apaches configtest) that  
cut configuration debug time down dramatically.

> BTW: instead of editing such a map file, you could also edit
> modules.conf and set 'unload => app_meetme.so'

Good to know for that specifically, which I will use for now.

I think what I am leaning towards and really desiring with this whole  
thing is that instead of just filing a bunch of individual bug reports  
or one big generic "fix the entire logging facility" bug report it  
would be nice to first know what would be the best way to do fix it.   
At the very least all the logging messages should be "synced up" so  
that the priorities are uniform.  But figuring out what that uniform  
"law" is is more than a one person decision.

>               Tzafrir Cohen

Daniel