[asterisk-bugs] [Asterisk 0014562]: [patch] safe_asterisk can get multiple instances if killproc escalates to SIGKILL in service asterisk restart

Asterisk Bug Tracker noreply at bugs.digium.com
Mon Nov 2 11:20:49 CST 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14562 
====================================================================== 
Reported By:                davidw
Assigned To:                tilghman
====================================================================== 
Project:                    Asterisk
Issue ID:                   14562
Category:                   General
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-02-26 12:37 CST
Last Modified:              2009-11-02 11:20 CST
====================================================================== 
Summary:                    [patch] safe_asterisk can get multiple instances if
killproc escalates to SIGKILL in service asterisk restart
Description: 
Weird behaviour was observed in which we got Remote UNIX connection and
disconnections continuously repeated.  It turned out that we had two copies
of safe_asterisk running.

Although I didn't do this myself, I believe this was the result of using
"service asterisk restart" on an asterisk that was in distress (deadlock,
at least).  I think what happened is that the killproc escalated to
SIGKILL, which was not recognized by the original safe_asterisk, so it
continued to run.  Meanwhile the new safe_asterisk was started, but both
checks for a running asterisk failed, either because it was too much in
distress, or because the console listener had shut down in response to
killproc's SIGTERM.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015846 Asterisk is looking in the wrong locati...
====================================================================== 

---------------------------------------------------------------------- 
 (0112975) svnbot (reporter) - 2009-11-02 11:20
 https://issues.asterisk.org/view.php?id=14562#c112975 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 226812

_U  trunk/
U   trunk/contrib/init.d/rc.redhat.asterisk

------------------------------------------------------------------------
r226812 | tilghman | 2009-11-02 11:20:48 -0600 (Mon, 02 Nov 2009) | 15
lines

Merged revisions 226811 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r226811 | tilghman | 2009-11-02 11:14:20 -0600 (Mon, 02 Nov 2009) | 8
lines
  
  Don't allow two separate instances of safe_asterisk when restarting from
the init script.
  (closes issue https://issues.asterisk.org/view.php?id=14562)
   Reported by: davidw
   Patches: 
         Initially 20091022__issue14562.diff.txt uploaded by tilghman
(license 14)
         Modified to 20091030__Issue14562_diff.txt uploaded by davidw
(license 780)
   Tested by: davidw
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=226812 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-11-02 11:20 svnbot         Checkin                                      
2009-11-02 11:20 svnbot         Note Added: 0112975                          
======================================================================




More information about the asterisk-bugs mailing list