[asterisk-bugs] [Asterisk 0016172]: [patch] "make config" creates really wrong runlevels in Debian (includes patch)

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Nov 3 12:01:09 CST 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16172 
====================================================================== 
Reported By:                ibc
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16172
Category:                   General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.26.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-11-03 10:37 CST
Last Modified:              2009-11-03 12:01 CST
====================================================================== 
Summary:                    [patch] "make config" creates really wrong runlevels
in Debian (includes patch)
Description: 
When running "make config" under Debian, it creates wrong runlevels:

  /etc# ls -l rc*/*asterisk*
  rc2.d/K91asterisk -> ../init.d/asterisk
  rc2.d/S50asterisk -> ../init.d/asterisk
  rc3.d/K91asterisk -> ../init.d/asterisk
  rc3.d/S50asterisk -> ../init.d/asterisk
  rc4.d/K91asterisk -> ../init.d/asterisk
  rc4.d/S50asterisk -> ../init.d/asterisk
  rc5.d/K91asterisk -> ../init.d/asterisk
  rc5.d/S50asterisk -> ../init.d/asterisk*

These runleves are really annoying and make no sense at all. Why are there
"K" entries in runleves 2, 3, 4 and 5?
"K" means "stop" action and the system never invoke
"/etc/init.d/SERVIC_NAME stop" in runleves 2, 3, 4 and 5. Instead, "stop"
action is just invoked in runleves 0 ("stop") and 6 ("reboot").
Also note that there is no "K" (stop) actions in runleves 0 and 6, so
asterisk is not terminated by the system when shuting down or rebooting.

For example, I show correct runlevels Kamailio creates when installing it
as Deb package:

  /etc# ls -l rc*/*kamailio*
  rc0.d/K23kamailio -> ../init.d/kamailio
  rc1.d/K23kamailio -> ../init.d/kamailio
  rc2.d/S23kamailio -> ../init.d/kamailio
  rc3.d/S23kamailio -> ../init.d/kamailio
  rc4.d/S23kamailio -> ../init.d/kamailio
  rc5.d/S23kamailio -> ../init.d/kamailio
  rc6.d/K23kamailio -> ../init.d/kamailio

This does make sense since "S" (start) actions exist for runlevels 1, 2,
3, 4 and 5 while "K" (stop) actions exist for 0 and 6.

In order to fix it I attach a patch for Asterisk Makefile (note that it's
based on Asterisk 1.4.26-rc4) which does the following:

- Creates "S" (start) actions in 1,2,3,4,5.
- Creates "K" (stop) actions in 0,6.
- The start actions have priority 50 (as now).
- The stop actions have priority 20. This is important in order Asterisk
to be shutdown before the system tries to shutdown dahdi, wanpipe and so
(in fact there is a bug with dahdi/wanpipe and the server crashes if dahdi
is shutdown before ending Asterisk).
====================================================================== 

---------------------------------------------------------------------- 
 (0113065) qwell (administrator) - 2009-11-03 12:01
 https://issues.asterisk.org/view.php?id=16172#c113065 
---------------------------------------------------------------------- 
If you look on a Debian system, you'll see that there are many services
that stop in runlevel 1.

2,3,4,5 and 0,1,6 would be appropriate.  Please adjust the patch to
reflect that. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-11-03 12:01 qwell          Note Added: 0113065                          
======================================================================




More information about the asterisk-bugs mailing list