[asterisk-bugs] [Asterisk 0017767]: Strange booting behavior depending on nice value

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17767 
====================================================================== 
Reported By:                elbriga
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17767
Category:                   Core/General
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.2.10 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-07-30 07:29 CDT
Last Modified:              2010-08-05 16:08 CDT
====================================================================== 
Summary:                    Strange booting behavior depending on nice value
Description: 
We're having some weird issues here with asterisk 1.6.2.10 (wasn't on the
list of versions)

After many try-n-fail attempts we concluded that the problem is around the
res_config_pgsql and the nice value when starting asterisk trough
safe_asterisk.

when the nice value is 0 (default of safe_asterisk) or lower it wont boot
correctly (I assume that not all modules get loaded, since core commands
like "reload" doesn't work), but when we use a higher nice value (less
priority) like 10 or more it will boot correctly. Curious is that when it
is in the "hanged" CLI state and we perform a "/etc/init.d/postgresql-8.3
restart" asterisk will "un-hang" and continue normal boot, eventually
reconnecting with postgres in normal operation.

Other thing we did was poke around with the res_config_pgsql, because it
appeared to be executing querys without being connected (probably the cause
of the hang). What we did was put a call to "pgsql_reconnect" in the
"find_table" method (because this method will do querys without calling the
reconnect method that makes sure we're connected), and that seemed to
resolve the problem.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-05 16:08 lmadsen        Description Updated                          
2010-08-05 16:08 lmadsen        Additional Information Updated                  
 
======================================================================